LUT Glitches
Allan Herriman
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.
Peter Alfke
"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
=============================================
Falk Brunner
>
> 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
Allan Herriman
<peter...@xilinx.com> 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.
Peter Alfke
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
Jim Granville
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
rk
> > 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
Bob Perlman
On Wed, 17 Oct 2001 16:47:20 +1300, Jim Granville
<jim.gr...@designtools.co.nz> 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
glen herrmannsfeldt
>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
Andy Peters
OK, so you've traded potential metastability in synchronous logic for
potential race conditions in asynchronous logic.
pick yr poison.
-a
glen herrmannsfeldt
>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
Bob Perlman
On 24 Oct 2001 02:18:47 GMT, g...@ugcs.caltech.edu (glen
herrmannsfeldt) wrote:
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
glen herrmannsfeldt
>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
Neil Franklin
>
> 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, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery
glen herrmannsfeldt
>g...@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