Scoping a glitch

[Allan Herriman]

On Sun, 22 May 2011 14:36:47 -0700, rickman wrote:

On May 21, 11:50 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sun, 22 May 2011 03:41:46 +0000, Allan Herriman wrote:

[snip]

Here 'tis, from a 2001 c.a.f thread:

http://groups.google.com/group/comp.arch.fpga/browse_thread/
thread/17a018858cc39a2d

Here is what [Peter Alfke] 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.

Ok, I think that means there would be no glitch even if both clock
inputs change at the same time.

mux clk1 clk2 output
0 0 0 0
0 0 1 0
0 1 1 1

...or...

mux clk1 clk2 output
0 0 0 0
0 1 0 1
0 1 1 1

I don't see how this could cause a glitch. I think what is being
remembered the classic race condition where if both inputs change at the
same time the output does not change. But given a small delta in the
propagation paths, the output can momentarily change to a value equal to
the output when only one input changes. In this case the unselected
clock causes no change in the output so that none of the intermediate
states are any different from and so no glitch occurs.

Am I figuring this wrong?

If I make some assumptions about how the LUTs work internally, I get the
same conclusion as you. Working with Peter's conditions, something like
an xor gate would definitely not be safe, but a 2 to 1 mux might be.


Regards,
Allan

 

[John Larkin]

On Mon, 16 May 2011 21:02:44 -0700, "Mr.CRC"
<crobcBOGUS@REMOVETHISsbcglobal.net> wrote:

Hi:

Today I took scope shots of a clock input to my Xilinx Spartan 3e,
Digilent NEXYS2 board. The clock goes to a counter, simulating a
quadrature encoder, as explained in post "Counter clocks on both edges
sometimes, but not when different IO pin is used" on 5-13-2011.

I have discovered that I'm dealing with a different animal here than
even the fastest logic chips I've grown comfortable with, the AC family.

We were recently playing with a Spartan 3, to see how narrow a pulse
we could count, using LVDS inputs feeding the first flop of a ripple
counter. 1 ns seemed to work OK.

We have seen slow input edges with a tiny amount of noise clock on the
wrong edge. Even CCLK does this!

Output edges are similarly screaming fast, sub-ns.

One can also do serious amounts of logic and get jitter in the 10s of
ps RMS.

They should give us a slow+schmitt input option.

John

 

[Mr.CRC]

John Larkin wrote:

On Mon, 16 May 2011 21:02:44 -0700, "Mr.CRC"
crobcBOGUS@REMOVETHISsbcglobal.net> wrote:

Hi:

Today I took scope shots of a clock input to my Xilinx Spartan 3e,
Digilent NEXYS2 board. The clock goes to a counter, simulating a
quadrature encoder, as explained in post "Counter clocks on both edges
sometimes, but not when different IO pin is used" on 5-13-2011.

I have discovered that I'm dealing with a different animal here than
even the fastest logic chips I've grown comfortable with, the AC family.


We were recently playing with a Spartan 3, to see how narrow a pulse
we could count, using LVDS inputs feeding the first flop of a ripple
counter. 1 ns seemed to work OK.

I would like to spend the time to spit my glitchy clock out a LVDS pair
to see if that can resolve the internal glitch.

Certainly a LVCMOS33 can't, or just barely shows a hint of inflection.

I also need to see if it's an asynchronous edge from another process
happening at the same time as the glitched clocks.

We have seen slow input edges with a tiny amount of noise clock on the
wrong edge. Even CCLK does this!

Output edges are similarly screaming fast, sub-ns.

One can also do serious amounts of logic and get jitter in the 10s of
ps RMS.

They should give us a slow+schmitt input option.

Yeah, I was thinking that too. A little too much to ask for I suppose.


--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

 

[rickman]

On May 26, 9:43 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:

John Larkin wrote:
On Mon, 16 May 2011 21:02:44 -0700, "Mr.CRC"
crobcBO...@REMOVETHISsbcglobal.net> wrote:

Hi:

Today I took scope shots of a clock input to my Xilinx Spartan 3e,
Digilent NEXYS2 board.  The clock goes to a counter, simulating a
quadrature encoder, as explained in post "Counter clocks on both edges
sometimes, but not when different IO pin is used" on 5-13-2011.

I have discovered that I'm dealing with a different animal here than
even the fastest logic chips I've grown comfortable with, the AC family.

We were recently playing with a Spartan 3, to see how narrow a pulse
we could count, using LVDS inputs feeding the first flop of a ripple
counter. 1 ns seemed to work OK.

I would like to spend the time to spit my glitchy clock out a LVDS pair
to see if that can resolve the internal glitch.

Certainly a LVCMOS33 can't, or just barely shows a hint of inflection.

I also need to see if it's an asynchronous edge from another process
happening at the same time as the glitched clocks.

What will you do with that information? Will it impact how you fix
the problem?

We have seen slow input edges with a tiny amount of noise clock on the
wrong edge. Even CCLK does this!

Output edges are similarly screaming fast, sub-ns.

One can also do serious amounts of logic and get jitter in the 10s of
ps RMS.

They should give us a slow+schmitt input option.

Yeah, I was thinking that too.  A little too much to ask for I suppose.

I/O features are market driven. Designs that use slow inputs are
mostly older technology that can afford to provide a buffer to sharpen
up the edge externally to the FPGA. Designs that use 1.8 volt IOs or
LVDS, etc, are higher technology which often need the more current
FPGA densities and features and are the apps that sell the higher
margin parts. Remember, the FPGA market is still driven by
communications apps. The industrial controls and most other apps
don't even show on the FPGA vendors' radar screens. So these apps get
what the FPGA makers provide and like it... or not... but that's what
they get anyway.

What about the makers of the SOC parts like Cypress and Actel, do they
include any Schmitt inputs?

Rick