From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: LUT Glitches Date: Tue, 16 Oct 2001 15:23:06 GMT Organization: Agilent Technologies Lines: 24 Message-ID: <3bcc4dd0.42807714@netnews.agilent.com> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1003245792 24202 130.29.154.45 (16 Oct 2001 15:23:12 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Tue, 16 Oct 2001 15:23:12 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@hpiw0398.aus.agilent.com X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!sdd.hp.com!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10716 Hi, I've gone over to the dark side and am implementing some *asynchronous* logic in a Xilinx Virtex-E FPGA. What are the conditions under which a LUT is guaranteed *not* to generate a glitch? I'm fairly sure this works if only one input is changing at a time. There used to be a statement about this in the databook (about XC3000 vintage, I think). What if multiple inputs are changing at the same time (i.e. within one LUT delay)? It's just a simple mux structure. I can separate the AND-OR structure of the mux into separate LUTs if I have to. The output is clocking an external device, so I really want to avoid glitches, at the same time as trying to keep the jitter low (i.e. I want the minimum number of LUTs in the signal path). Thanks, Allan. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: Tue, 16 Oct 2001 09:58:20 -0700 Organization: Xilinx Lines: 97 Message-ID: <3BCC672C.47CAE5A3@xilinx.com> References: <3bcc4dd0.42807714@netnews.agilent.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------432C8FFB8D8F4D41FE84959F" X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en To: Allan Herriman Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.r-kom.de!news0.de.colt.net!colt.net!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsswitch.lcs.mit.edu!cyclone.bc.net!sjcppf01.usenetserver.com!usenetserver.com!easynews!sjc-peer.news.verio.net!dfw-feed.news.verio.net!news.verio.net!nntp1.hal-pc.org!12.120.16.16.MISMATCH!attdl1!attdl2!attsl2!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10688 --------------432C8FFB8D8F4D41FE84959F Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Here is what I wrote ten years ago ( you can find it, among other places, in the 1994 data book, page 9-5: "Function Generator Avoids Glitches ... Note that there can never be a decoding glitch when only one select input changes. Even a non-overlapping decoder cannot generate a glitch problem, since the node capacitance would retain the previous logic level... When more than one input changes "simultaneously", the user should analyze the logic output for any intermediate code. If any such code produces a different result, the user must assume that such a glitch might occur, and must make the system design immune to it... If none of the address codes contained in the "simultaneously" changing inputs produces a different output, the user can be sure that there will be no glitch...." This still applies today. Peter Alfke, Xilinx Applications ============================================= Allan Herriman wrote: > Hi, > > I've gone over to the dark side and am implementing some > *asynchronous* logic in a Xilinx Virtex-E FPGA. > > What are the conditions under which a LUT is guaranteed *not* to > generate a glitch? > > I'm fairly sure this works if only one input is changing at a time. > There used to be a statement about this in the databook (about XC3000 > vintage, I think). > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? > > It's just a simple mux structure. I can separate the AND-OR structure > of the mux into separate LUTs if I have to. > > The output is clocking an external device, so I really want to avoid > glitches, at the same time as trying to keep the jitter low (i.e. I > want the minimum number of LUTs in the signal path). > > Thanks, > Allan. --------------432C8FFB8D8F4D41FE84959F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here is what I wrote ten years ago ( you can find it, among other places, in the 1994 data book, page 9-5:

"Function Generator Avoids Glitches
...
Note that there can never be a decoding glitch when only one select input changes. Even a non-overlapping decoder cannot generate a glitch problem, since the node capacitance would retain the previous logic level...
When more than one input changes "simultaneously", the user should analyze the logic output for any intermediate code. If any such code produces a different result, the user must assume that such a glitch might occur, and must make the system design immune to it...
If none of the address codes contained in the "simultaneously" changing inputs produces a different output, the user can be sure that there will be no glitch...."

This still applies today.

Peter Alfke, Xilinx Applications
=============================================
Allan Herriman wrote:

Hi,

I've gone over to the dark side and am implementing some
*asynchronous* logic in a Xilinx Virtex-E FPGA.

What are the conditions under which a LUT is guaranteed *not* to
generate a glitch?

I'm fairly sure this works if only one input is changing at a time.
There used to be a statement about this in the databook (about XC3000
vintage, I think).

What if multiple inputs are changing at the same time (i.e. within one
LUT delay)?

It's just a simple mux structure.  I can separate the AND-OR structure
of the mux into separate LUTs if I have to.

The output is clocking an external device, so I really want to avoid
glitches, at the same time as trying to keep the jitter low (i.e. I
want the minimum number of LUTs in the signal path).

Thanks,
Allan.

--------------432C8FFB8D8F4D41FE84959F-- ###### From: Falk Brunner Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: Tue, 16 Oct 2001 23:09:12 +0200 Lines: 16 Message-ID: <3BCCA1F8.6DA1B56F@gmx.de> References: <3bcc4dd0.42807714@netnews.agilent.com> NNTP-Posting-Host: pec-58-68.tnt4.b2.uunet.de (149.225.58.68) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1003266877 25167647 149.225.58.68 (16 [84877]) X-Mailer: Mozilla 4.08 [de] (Win95; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!43826!news.imp.ch!fu-berlin.de!uni-berlin.de!pec-58-68.tnt4.b2.uunet.DE!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10733 Allan Herriman schrieb: > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? I would be VERY carefull about this. Why? Because the LUTs and the FF inside the FPGA are DAMM fast. Just wait some days, I did some experiments and will publish them in a few days. You will be scared (I think). -- MFG Falk ###### From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: Wed, 17 Oct 2001 01:53:43 GMT Organization: Agilent Technologies Lines: 56 Message-ID: <3bcce3bc.1562817@netnews.agilent.com> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCC672C.47CAE5A3@xilinx.com> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1003283628 8146 130.29.154.45 (17 Oct 2001 01:53:48 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Wed, 17 Oct 2001 01:53:48 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@hpiw0398.aus.agilent.com X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!sdd.hp.com!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10715 On Tue, 16 Oct 2001 09:58:20 -0700, Peter Alfke wrote: >Here is what I wrote ten years ago ( you can find it, among other places, in the >1994 data book, page 9-5: > >"Function Generator Avoids Glitches >... >Note that there can never be a decoding glitch when only one select input >changes. Even a non-overlapping decoder cannot generate a glitch problem, since >the node capacitance would retain the previous logic level... >When more than one input changes "simultaneously", the user should analyze the >logic output for any intermediate code. If any such code produces a different >result, the user must assume that such a glitch might occur, and must make the >system design immune to it... >If none of the address codes contained in the "simultaneously" changing inputs >produces a different output, the user can be sure that there will be no >glitch...." > >This still applies today. Thankyou. Marc Baker from Xilinx emailed and pointed out that this is also in http://www.xilinx.com/xapp/xapp024.pdf Regards, Allan. >Allan Herriman wrote: > >> Hi, >> >> I've gone over to the dark side and am implementing some >> *asynchronous* logic in a Xilinx Virtex-E FPGA. >> >> What are the conditions under which a LUT is guaranteed *not* to >> generate a glitch? >> >> I'm fairly sure this works if only one input is changing at a time. >> There used to be a statement about this in the databook (about XC3000 >> vintage, I think). >> >> What if multiple inputs are changing at the same time (i.e. within one >> LUT delay)? >> >> It's just a simple mux structure. I can separate the AND-OR structure >> of the mux into separate LUTs if I have to. >> >> The output is clocking an external device, so I really want to avoid >> glitches, at the same time as trying to keep the jitter low (i.e. I >> want the minimum number of LUTs in the signal path). >> >> Thanks, >> Allan. ###### Message-ID: <3BCCEA05.EDC9D446@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCA1F8.6DA1B56F@gmx.de> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 21 Date: Wed, 17 Oct 2001 02:16:43 GMT NNTP-Posting-Host: 216.244.43.77 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1003285003 216.244.43.77 (Tue, 16 Oct 2001 19:16:43 PDT) NNTP-Posting-Date: Tue, 16 Oct 2001 19:16:43 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Tue, 16 Oct 2001 19:13:03 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!colt.net!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10703 Falk Brunner wrote: > Allan Herriman schrieb: > > > > What if multiple inputs are changing at the same time (i.e. within one > > LUT delay)? > > I would be VERY carefull about this. Why? Because the LUTs and the FF > inside the FPGA are DAMM fast. > Just wait some days, I did some experiments and will publish them in a > few days. Interesting, but my posted answer covers all speeds up to and including infinity. So there is no additional caveat. Still, always looking forward to experimental data... Peter Alfke ###### Message-ID: <3BCCFF48.25C3@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: LUT Glitches References: <3bcc4dd0.42807714@netnews.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 49 Date: Wed, 17 Oct 2001 16:47:20 +1300 NNTP-Posting-Host: 203.79.98.121 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1003290496 203.79.98.121 (Wed, 17 Oct 2001 16:48:16 NZDT) NNTP-Posting-Date: Wed, 17 Oct 2001 16:48:16 NZDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!news.mel.connect.com.au!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10706 Allan Herriman wrote: > > Hi, > > I've gone over to the dark side and am implementing some > *asynchronous* logic in a Xilinx Virtex-E FPGA. > > What are the conditions under which a LUT is guaranteed *not* to > generate a glitch? > > I'm fairly sure this works if only one input is changing at a time. > There used to be a statement about this in the databook (about XC3000 > vintage, I think). > > What if multiple inputs are changing at the same time (i.e. within one > LUT delay)? > > It's just a simple mux structure. I can separate the AND-OR structure > of the mux into separate LUTs if I have to. > > The output is clocking an external device, so I really want to avoid > glitches, at the same time as trying to keep the jitter low (i.e. I > want the minimum number of LUTs in the signal path). > > Thanks, > Allan. We've done this in CPLD, not FPGA, but the concept is portable: - you can make glitch filters, from tapped delay lines, and a majority vote scheme. - When creating clocks from delay logic, it is possible, in theory, to have more than one stable 'traveling-wave', so to avoid this we Gate the osc to start from a known state - The tools need to be watched, sometimes they will optimise out important delay element(s) :-) - We had one interesting bench setup, to self test a delay-osc, and the LSB's of the display were in the femto-second region. Of sourse, they moved around, but it was stable to < 10ps which I thought was quite impressive. ( at a given Temp/Vcc ) The 'delay' quantizer in these PLDs (ATF1504) was 2.7ns - your FPGA numbers will be << 1ns -jg ###### From: rk Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: Wed, 17 Oct 2001 08:07:07 -0400 Organization: Just an OldEngineer Lines: 23 Message-ID: <3BCD746B.2A5CA426@nospamplease.erols.com> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCA1F8.6DA1B56F@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVa0beOG+33iCU32GDgmFUEDwn2x26knGaWMwmwTmN0HbaROGJ6GI8P5 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 17 Oct 2001 12:06:01 GMT X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10721 Falk Brunner wrote: > > What if multiple inputs are changing at the same time (i.e. within one > > LUT delay)? > > I would be VERY carefull about this. Why? Because the LUTs and the FF > inside the FPGA are DAMM fast. > Just wait some days, I did some experiments and will publish them in a > few days. > You will be scared (I think). I look forward to it, please post it. Quicklogic had a similar guarantee (obviously not LUT-based logic) in their old data book about the logic not glitching under certain circumstances. There is nothing like real data to f' up a great theory. -- rk, circa 1995 -- rk Just an OldEngineer ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Message-ID: References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 42 Date: Wed, 17 Oct 2001 15:16:51 GMT NNTP-Posting-Host: 24.221.179.83 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1003331811 24.221.179.83 (Wed, 17 Oct 2001 08:16:51 PDT) NNTP-Posting-Date: Wed, 17 Oct 2001 08:16:51 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Wed, 17 Oct 2001 08:13:01 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed2.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:10685 Hi - On Wed, 17 Oct 2001 16:47:20 +1300, Jim Granville wrote: > > We've done this in CPLD, not FPGA, but the concept is portable: > >- you can make glitch filters, from tapped delay lines, and a majority > vote scheme. You can build glitch filters with tapped delay lines and majority detection logic, but with an important caveat. These filters will eliminate pulses shorter than X ns and pass pulses longer than Y ns, but X and Y aren't the same number. In between X and Y, the circuit can misbehave; there's a range of pulse durations that can produce glitches at the output of the filter. If there were such a thing as a perfect glitch filter, we could build a metastable-proof flip-flop by filtering out runt pulses. Were it that it were. Bob Perlman >- When creating clocks from delay logic, it is possible, in theory, to > have more than one stable 'traveling-wave', so to avoid this we > Gate the osc to start from a known state > >- The tools need to be watched, sometimes they will optimise out > important delay element(s) :-) > >- We had one interesting bench setup, to self test a delay-osc, > and the LSB's of the display were in the femto-second region. > Of sourse, they moved around, but it was stable to < 10ps > which I thought was quite impressive. > ( at a given Temp/Vcc ) > > The 'delay' quantizer in these PLDs (ATF1504) was 2.7ns >- your FPGA numbers will be << 1ns > >-jg ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: 24 Oct 2001 02:18:47 GMT Organization: California Institute of Technology, Pasadena Lines: 19 Message-ID: <9r58e7$npr@gap.cco.caltech.edu> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> NNTP-Posting-Host: yak.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!43463!news.imp.ch!fu-berlin.de!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch comp.arch.fpga:10877 Bob Perlman writes: >You can build glitch filters with tapped delay lines and majority >detection logic, but with an important caveat. These filters will >eliminate pulses shorter than X ns and pass pulses longer than Y ns, >but X and Y aren't the same number. In between X and Y, the circuit >can misbehave; there's a range of pulse durations that can produce >glitches at the output of the filter. >If there were such a thing as a perfect glitch filter, we could build >a metastable-proof flip-flop by filtering out runt pulses. Were it >that it were. The original question asked about asynchronous logic, which doesn't have a metastability problem. Asynchronous logic, also called self timed logic, runs as fast as gates can change. Look up self-timed logic somewhere. -- glen ###### Message-ID: <3BD84FC3.73E7A46E@exponentmedia.deletethis.com> From: Andy Peters X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 26 Date: Thu, 25 Oct 2001 17:45:41 GMT NNTP-Posting-Host: 24.221.131.16 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1004031941 24.221.131.16 (Thu, 25 Oct 2001 10:45:41 PDT) NNTP-Posting-Date: Thu, 25 Oct 2001 10:45:41 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Thu, 25 Oct 2001 10:41:51 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10982 glen herrmannsfeldt wrote: > > Bob Perlman writes: > > >You can build glitch filters with tapped delay lines and majority > >detection logic, but with an important caveat. These filters will > >eliminate pulses shorter than X ns and pass pulses longer than Y ns, > >but X and Y aren't the same number. In between X and Y, the circuit > >can misbehave; there's a range of pulse durations that can produce > >glitches at the output of the filter. > > >If there were such a thing as a perfect glitch filter, we could build > >a metastable-proof flip-flop by filtering out runt pulses. Were it > >that it were. > > The original question asked about asynchronous logic, which doesn't > have a metastability problem. Asynchronous logic, also called self > timed logic, runs as fast as gates can change. Look up self-timed > logic somewhere. OK, so you've traded potential metastability in synchronous logic for potential race conditions in asynchronous logic. pick yr poison. -a ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: 25 Oct 2001 23:47:10 GMT Organization: California Institute of Technology, Pasadena Lines: 50 Message-ID: <9ra89u$bo5@gap.cco.caltech.edu> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> <3BD84FC3.73E7A46E@exponentmedia.deletethis.com> NNTP-Posting-Host: yak.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.bme.hu!news.matavnet.hu!newsfeed.matavnet.hu!news.dtag.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch comp.arch.fpga:10926 Andy Peters writes: >glen herrmannsfeldt wrote: >> >> The original question asked about asynchronous logic, which doesn't >> have a metastability problem. Asynchronous logic, also called self >> timed logic, runs as fast as gates can change. Look up self-timed >> logic somewhere. >OK, so you've traded potential metastability in synchronous logic for >potential race conditions in asynchronous logic. >pick yr poison. I thought self-timed logic didn't have a race condition problem. Note that 'asynchronous logic' can have other meanings, including ones that have race conditions, so I prefer the term 'self-timed logic.' I believe that self-timed logic can't have race conditions. As previously stated, though, it is sensitive to glitches. If a gate input changes, but the gate output is independent of that change, the gate output should not glitch. An FPGA lookup table representing a gate with more than two inputs, does not necessarily have this property. I will try a simple description of self-timed logic, as it was explained to me about twenty years ago, and someone can correct it if I am too far off. Each signal has three states, normally represented with two wires. The third state is the indeterminate state, when the final value isn't yet known. It only goes to the final state when the final value is known, so no race conditions. Hysteresis is applied in the right place to eliminate race conditions, such that each signal must go through the indeterminate state before it can go to the final state. The result is that without a clock, and without race conditions, each output gets to its final value as fast as the signals can propagate through the logic. If a flip-flop goes metastable the rest of the logic waits until it goes to a stable state. A web search came up with: http://www.theseus.com/PDF/japan_paper.pdf which seems to have a reasonable description. -- glen ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Message-ID: References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> X-Newsreader: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 33 Date: Fri, 26 Oct 2001 05:08:22 GMT NNTP-Posting-Host: 24.221.179.83 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1004072902 24.221.179.83 (Thu, 25 Oct 2001 22:08:22 PDT) NNTP-Posting-Date: Thu, 25 Oct 2001 22:08:22 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Thu, 25 Oct 2001 22:04:31 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed2.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:10947 Hi - On 24 Oct 2001 02:18:47 GMT, gah@ugcs.caltech.edu (glen herrmannsfeldt) wrote: >Bob Perlman writes: > >>You can build glitch filters with tapped delay lines and majority >>detection logic, but with an important caveat. These filters will >>eliminate pulses shorter than X ns and pass pulses longer than Y ns, >>but X and Y aren't the same number. In between X and Y, the circuit >>can misbehave; there's a range of pulse durations that can produce >>glitches at the output of the filter. > >>If there were such a thing as a perfect glitch filter, we could build >>a metastable-proof flip-flop by filtering out runt pulses. Were it >>that it were. > >The original question asked about asynchronous logic, which doesn't >have a metastability problem. Asynchronous logic, also called self >timed logic, runs as fast as gates can change. Look up self-timed >logic somewhere. I wasn't responding to the original question (this is Usenet, after all), but to the comment about building glitch filters from tapped delay lines. Nor was I claiming that self-timed logic was inherently susceptible to metastability. What do I think of self-timed logic? Read this: http://www.isdmag.com/editorial/2000/feedback0007.html Bob Perlman ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: 26 Oct 2001 17:33:26 GMT Organization: California Institute of Technology, Pasadena Lines: 52 Message-ID: <9rc6p6$8m4@gap.cco.caltech.edu> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> NNTP-Posting-Host: yak.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch comp.arch.fpga:10921 Bob Perlman writes: >On 24 Oct 2001 02:18:47 GMT, gah@ugcs.caltech.edu (glen >herrmannsfeldt) wrote: >>Bob Perlman writes: >> >>>You can build glitch filters with tapped delay lines and majority >>>detection logic, but with an important caveat. These filters will >>>eliminate pulses shorter than X ns and pass pulses longer than Y ns, >>>but X and Y aren't the same number. In between X and Y, the circuit >>>can misbehave; there's a range of pulse durations that can produce >>>glitches at the output of the filter. >> >>>If there were such a thing as a perfect glitch filter, we could build >>>a metastable-proof flip-flop by filtering out runt pulses. Were it >>>that it were. >> >>The original question asked about asynchronous logic, which doesn't >>have a metastability problem. Asynchronous logic, also called self >>timed logic, runs as fast as gates can change. Look up self-timed >>logic somewhere. >I wasn't responding to the original question (this is Usenet, after >all), but to the comment about building glitch filters from tapped >delay lines. Nor was I claiming that self-timed logic was inherently >susceptible to metastability. >What do I think of self-timed logic? Read this: >http://www.isdmag.com/editorial/2000/feedback0007.html Sorry for the confusion. It is sometimes hard to figure which direction a thread is going in. OK, I read the editorial, and the replies to it. I think I agree with all of them. One is that the current design tools are designed around synchronous logic, making it hard to do non-synchronous designs. (I have never done a self-timed logic design, but I used to talk about it with people who had done it. Otherwise I wouldn't know about it at all.) It might be, as one reply says, it is like RISC, where the time came and, after looking for a while in disbelief, everyone finally jumped on. I was just considering how, without a clock frequency to advertize how are companies going to convince people that their new processor is the fastest? The marketing department might kill anything asynchronous! I used to hear stories that the PDP-10 was asynchronous, but I have now found that other PDP-10 stories were false, so that one may be also. -- glen ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: 26 Oct 2001 23:32:56 +0200 Organization: My own Private Self Lines: 48 Message-ID: <6uvgh2hyt3.fsf@chonsp.franklin.ch> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> <9rc6p6$8m4@gap.cco.caltech.edu> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1004131977 494 10.0.3.2 (26 Oct 2001 21:32:57 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 26 Oct 2001 21:32:57 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:10987 gah@ugcs.caltech.edu (glen herrmannsfeldt) writes: > > It might be, as one reply says, it is like RISC, where the time came > and, after looking for a while in disbelief, everyone finally jumped on. Everyone except Intel, who makes 90% of all PC-sized processors :-). > I was just considering how, without a clock frequency to advertize how > are companies going to convince people that their new processor is the > fastest? The marketing department might kill anything asynchronous! Switch to real app level benchmarks, like SPEC? AMD is already trying to do this, because their Athlon design is lower clock/power than Intels P4. > I used to hear stories that the PDP-10 was asynchronous, but I have > now found that other PDP-10 stories were false, so that one may be also. The earlier PDP-10s CPU models (166, KA-10) were hardwired async, they then switched to hardwired sync (KI-10) and later to microcoded sync (KL-10 and KS-10). Data from: http://www.inwap.com/pdp10/models.txt Year announced 1964 1967 1972 1978 cancel 1994 CPU type 166 KA KI KS KC XKL-1 Clock speed nanoseconds Async Async 110 50 Fast 30 Year announced 1974 1974 ?78? 1981 1976 ?78? 1976 ?78? ?81? ?84? CPU type KL-A KL-B KL-D KL-E KL-C KL-D KL-C KL-D KL-E KL-R Model-B backplane ucode No No Yes Yes No Yes No Yes Yes PW Clock speed nanoseconds 40 40 33 33 40 33 40 33 33 33 P.S. I am working (hobby, so slowly) on cloning the KI-10 in an Spartan-II: http://neil.franklin.ch/Projects/PDP-10/ -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual Robbery ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: comp.arch.fpga Subject: Re: LUT Glitches Date: 27 Oct 2001 21:22:47 GMT Organization: California Institute of Technology, Pasadena Lines: 26 Message-ID: <9rf8j7$gni@gap.cco.caltech.edu> References: <3bcc4dd0.42807714@netnews.agilent.com> <3BCCFF48.25C3@designtools.co.nz> <9r58e7$npr@gap.cco.caltech.edu> <9rc6p6$8m4@gap.cco.caltech.edu> <6uvgh2hyt3.fsf@chonsp.franklin.ch> NNTP-Posting-Host: lek.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!205.231.236.10!newspeer.monmouth.com!newsswitch.lcs.mit.edu!news.uchicago.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch comp.arch.fpga:11024 Neil Franklin writes: >gah@ugcs.caltech.edu (glen herrmannsfeldt) writes: >> >> It might be, as one reply says, it is like RISC, where the time came >> and, after looking for a while in disbelief, everyone finally jumped on. >Everyone except Intel, who makes 90% of all PC-sized processors :-). who also makes the i860. (snip) >> I used to hear stories that the PDP-10 was asynchronous, but I have >> now found that other PDP-10 stories were false, so that one may be also. >The earlier PDP-10s CPU models (166, KA-10) were hardwired async, they >then switched to hardwired sync (KI-10) and later to microcoded sync >(KL-10 and KS-10). Thanks. It was a KA-10 that I used to use. >Data from: >http://www.inwap.com/pdp10/models.txt (snip) -- glen