Scoping a glitch

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.

First is the input to the NEXYS2 IO connector pin, driven by a TI
ISO7240c chip, with about a 150 series resistor.  This shows an
incidence where the counter incorrectly counted on the falling edge:

http://web.newsguy.com/crobcng/spartan3e/scope_11.png

The falling edge which caused the glitch:

http://web.newsguy.com/crobcng/spartan3e/scope_12.png

At this point I was thinking, "there is no reason for this to be a
problem."  As any discrete logic chip would never glitch with this.

Nonetheless, the evidence is that internally the counter is seeing a
rising edge here, so there must be a brief upward wiggle internally.
How to see this?  I can't really.  The best I can do is take a copy of
the internal signal, and spit it back out another IO port.

Here is where things get weird.  Depending on which pins are chosen, it
is possible that the glitches will go away when a copy is sent out an IO
port.  An important additional clue was the fact that an adjacent pin to
the clock input, when changed from unconfigured (input) to output, even
if just a static logic level was output, caused the glitching to go
away.  More on that later.

Here is the scope looking at the output from the FPGA, of a copy of the
internal clock, again captured on an offending falling edge causing an
incorrect count (note this just looks the same as scope_12.png above:

http://web.newsguy.com/crobcng/spartan3e/scope_13.png

But when zoomed in, there is the slightest wiggle present:

http://web.newsguy.com/crobcng/spartan3e/scope_14.png

Now this is a 500MHz scope with a 500MHz probe, and very short (1.5cm)
ground lead, so this is a good probing setup.  That little wiggle is
nearly a Ghz!  Due to at least -6dB of attenuation from the scope +
probe, the actual wiggle is probably twice or more than the amplitude
shown, which is barely anything.

Now this is of course NOT what the internal signal looks like, of
course, because it had to go through an output buffer.  Also, the choice
of LVCMOS 3.3V makes this perhaps the slowest output possible.

But it seems like the output buffer is trying to tell us something,
about what the internal signal looks like.  It has a friggin' glitch!

I also zoomed in on several adjacent falling edges, ones which did not
cause a counter glitch.  These have at most a "shelf" at the same level,
but no slope reversal.  Most have just an inflection.  There is a
pattern here.


Finally, I replaced the driver of the input pin from the relatively high
impedance source to a terminated 50 ohm cable with 10ns edges coming
directly from a generator, and the glitches stopped.  This is consistent
with the fact that the behavior changes in relation to the change in
impedance of a pin adjacent to the input pin.


This is fascinating.  I have to wrap my head around the fact that things
can be happening inside the chip at the near GHz rate, so the magnitude
of the signal integrity requirement stringency is about an order of
magnitude more demanding than I'm used to.


I would like to scope this again with my 1GHz scope (the one I thought
I'd only ever need for my optical parametric oscillator work), and see
if also I can get a faster, lower voltage signaling standard selected.
I'm not sure if the NEXYS2 board will let that happen.  We'll see.

I'm also curious to see what will happen if the edge time is slowed
down, but the drive impedance is still low.  Fortunately my generator
has adjustable slew rates, so I can check this out too.


Well at least now I know what is really going on.


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

The ususal suspect here is ground bounce. If outputs are switching at the
same time that the clock edge occurs the wiggle you see on the scope is also
partly present on the GND pin(s), and so also seen superimposed on the CLK
signal by the CLK input buffer.
A simple test is dividing the CLK by 2 and sending that to an output pin.
You will immediately see the non-periodic pattern and most scopes can
trigger on a pulse that is longer than a CLK period.
Fast CLK edges will prevent this problem, but your CLK is far from perfect 
(for a fast chip, that is...).

Regards,
Arie de Muynck


"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message
news:iqss1601vk@news6.newsguy.com...
> 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.
>
> First is the input to the NEXYS2 IO connector pin, driven by a TI
> ISO7240c chip, with about a 150 series resistor.  This shows an
> incidence where the counter incorrectly counted on the falling edge:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_11.png
>
> The falling edge which caused the glitch:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_12.png
>
> At this point I was thinking, "there is no reason for this to be a
> problem."  As any discrete logic chip would never glitch with this.
>
> Nonetheless, the evidence is that internally the counter is seeing a
> rising edge here, so there must be a brief upward wiggle internally.
> How to see this?  I can't really.  The best I can do is take a copy of
> the internal signal, and spit it back out another IO port.
>
> Here is where things get weird.  Depending on which pins are chosen, it
> is possible that the glitches will go away when a copy is sent out an IO
> port.  An important additional clue was the fact that an adjacent pin to
> the clock input, when changed from unconfigured (input) to output, even
> if just a static logic level was output, caused the glitching to go
> away.  More on that later.
>
> Here is the scope looking at the output from the FPGA, of a copy of the
> internal clock, again captured on an offending falling edge causing an
> incorrect count (note this just looks the same as scope_12.png above:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_13.png
>
> But when zoomed in, there is the slightest wiggle present:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_14.png
>
> Now this is a 500MHz scope with a 500MHz probe, and very short (1.5cm)
> ground lead, so this is a good probing setup.  That little wiggle is
> nearly a Ghz!  Due to at least -6dB of attenuation from the scope +
> probe, the actual wiggle is probably twice or more than the amplitude
> shown, which is barely anything.
>
> Now this is of course NOT what the internal signal looks like, of
> course, because it had to go through an output buffer.  Also, the choice
> of LVCMOS 3.3V makes this perhaps the slowest output possible.
>
> But it seems like the output buffer is trying to tell us something,
> about what the internal signal looks like.  It has a friggin' glitch!
>
> I also zoomed in on several adjacent falling edges, ones which did not
> cause a counter glitch.  These have at most a "shelf" at the same level,
> but no slope reversal.  Most have just an inflection.  There is a
> pattern here.
>
>
> Finally, I replaced the driver of the input pin from the relatively high
> impedance source to a terminated 50 ohm cable with 10ns edges coming
> directly from a generator, and the glitches stopped.  This is consistent
> with the fact that the behavior changes in relation to the change in
> impedance of a pin adjacent to the input pin.
>
>
> This is fascinating.  I have to wrap my head around the fact that things
> can be happening inside the chip at the near GHz rate, so the magnitude
> of the signal integrity requirement stringency is about an order of
> magnitude more demanding than I'm used to.
>
>
> I would like to scope this again with my 1GHz scope (the one I thought
> I'd only ever need for my optical parametric oscillator work), and see
> if also I can get a faster, lower voltage signaling standard selected.
> I'm not sure if the NEXYS2 board will let that happen.  We'll see.
>
> I'm also curious to see what will happen if the edge time is slowed
> down, but the drive impedance is still low.  Fortunately my generator
> has adjustable slew rates, so I can check this out too.
>
>
> Well at least now I know what is really going on.
>
>
> -- 
> _____________________
> Mr.CRC
> crobcBOGUS@REMOVETHISsbcglobal.net
> SuSE 10.3 Linux 2.6.22.17

Arie de Muynck wrote:
> The ususal suspect here is ground bounce. If outputs are switching at the
> same time that the clock edge occurs the wiggle you see on the scope is
> also
> partly present on the GND pin(s), and so also seen superimposed on the CLK
> signal by the CLK input buffer.
> A simple test is dividing the CLK by 2 and sending that to an output pin.
> You will immediately see the non-periodic pattern and most scopes can
> trigger on a pulse that is longer than a CLK period.
> Fast CLK edges will prevent this problem, but your CLK is far from
> perfect (for a fast chip, that is...).
> 
> Regards,
> Arie de Muynck


Indeed.

Why on earth don't they put some hysteresis on the inputs to these silly
chips?

Thanks for the reply!

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

> First is the input to the NEXYS2 IO connector pin, driven by a TI
> ISO7240c chip, with about a 150 series resistor.  This shows an
> incidence where the counter incorrectly counted on the falling edge:

What's the signal path to the FPGA?

> The falling edge which caused the glitch:
> http://web.newsguy.com/crobcng/spartan3e/scope_12.png

What exactly are you scoping here?

Ch3&4 are at 5V, is there some current/voltage limiting device between
the pins and the FPGA?

Are ch3 and ch4 your quadrature encoder inputs?

What's ch1 looking at?

If that falling edge is an input than at ~30ns it's shouldn't be what's causing
the problem unless you've got _terrible_ ground problems.

> Here is where things get weird.  Depending on which pins are chosen, it
> is possible that the glitches will go away when a copy is sent out an IO
> port.  An important additional clue was the fact that an adjacent pin to
> the clock input, when changed from unconfigured (input) to output, even
> if just a static logic level was output, caused the glitching to go
> away.  More on that later.


This shows your design is still susceptible to asynchronous inputs toggling.

Synchronise both(all) the inputs at the IO to the system clock then use those
to look for falling or rising edges for your counter





Nial 

Nial Stewart wrote:
>> First is the input to the NEXYS2 IO connector pin, driven by a TI
>> ISO7240c chip, with about a 150 series resistor.  This shows an
>> incidence where the counter incorrectly counted on the falling edge:
> 
> What's the signal path to the FPGA?

The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
connect to a research lab.  The output of the ISO (input to FPGA) at
3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
header pin on the Digilent NEXYS2 board.

>> The falling edge which caused the glitch:
>> http://web.newsguy.com/crobcng/spartan3e/scope_12.png
> 
> What exactly are you scoping here?

That is a horizontally magnified view of the input to the FPGA (ch1
"A0") measured at the Digilent board pin, with 1.5cm probe ground to the
Digilent pin.  The other channels are outputs from the FPGA, after they
pass through output buffering devices and level translation to 5V on the
buffering panel.

> Ch3&4 are at 5V, is there some current/voltage limiting device between
> the pins and the FPGA?
> 
> Are ch3 and ch4 your quadrature encoder inputs?

Buffered, translated outputs from the FPGA, they go out the panel and
also at 3.3V go to a TI TMS320F2812.

> What's ch1 looking at?

Explained above.

> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
> the problem unless you've got _terrible_ ground problems.

Well if there are ground problems, they are out of my control, as this
is the signal at the pin on the Digilent board.  I would expect them to
have done a competent job.

I'm not sure, is there a history of people complaining about Digilent
board signal integrity problems?

>> Here is where things get weird.  Depending on which pins are chosen, it
>> is possible that the glitches will go away when a copy is sent out an IO
>> port.  An important additional clue was the fact that an adjacent pin to
>> the clock input, when changed from unconfigured (input) to output, even
>> if just a static logic level was output, caused the glitching to go
>> away.  More on that later.
> 
> 
> This shows your design is still susceptible to asynchronous inputs toggling.

The important other fact is that if the drive impedance is made stiffer
(180->50ohms) and speed to the FPGA input increased (30->10ns) then the
glitches are no longer observed, even after an all night wait.

> Synchronise both(all) the inputs at the IO to the system clock then use those
> to look for falling or rising edges for your counter

Yeah, tried that.  Works.  I think I have things under control, with two
possible choices of path forward.

Thanks for the feedback.



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

>> What's the signal path to the FPGA?
> > The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
> connect to a research lab.  The output of the ISO (input to FPGA) at
> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
> header pin on the Digilent NEXYS2 board.

Then it's probably not a ground problem, especially if this is the only
input to the FPGA.

> That is a horizontally magnified view of the input to the FPGA (ch1
> "A0") measured at the Digilent board pin, with 1.5cm probe ground to the
> Digilent pin.

Does that go straight to the FPGA?

Is this what it's seeing?

>> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
>> the problem unless you've got _terrible_ ground problems.
>
> Well if there are ground problems, they are out of my control, as this
> is the signal at the pin on the Digilent board.  I would expect them to
> have done a competent job.
> I'm not sure, is there a history of people complaining about Digilent
> board signal integrity problems?

No, as above this almost definitely isn't a problem.

>> This shows your design is still susceptible to asynchronous inputs toggling.
>
> The important other fact is that if the drive impedance is made stiffer
> (180->50ohms) and speed to the FPGA input increased (30->10ns) then the
> glitches are no longer observed, even after an all night wait.

There could be a race condition internally which stops being a factor when
you speed up the inputs.

Depending on your build, choice of pins etc this could be re-introduced at
any point.

:-)

>> Synchronise both(all) the inputs at the IO to the system clock then use those
>> to look for falling or rising edges for your counter
>
> Yeah, tried that.  Works.  I think I have things under control, with two
> possible choices of path forward.

No, there's _only_ one path forward, synchronise your inputs.

The input you're looking at is _reasonably_ fast, how fast is the internal clock
you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this
clock.

> Thanks for the feedback.

No problem, other people's problems are always interesting!



Nial

On 5/18/2011 7:50 AM, Nial Stewart wrote:
> No problem, other people's problems are always interesting!

"It's funny 'cause it's true." as Homer Simpson said.
Time for me to get back to making some more-interesting problems.

          -- Mike Treseler

Nial Stewart wrote:
>>> What's the signal path to the FPGA?
>>> The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
>> connect to a research lab.  The output of the ISO (input to FPGA) at
>> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
>> header pin on the Digilent NEXYS2 board.
> 
> Then it's probably not a ground problem, especially if this is the only
> input to the FPGA.
> 
>> That is a horizontally magnified view of the input to the FPGA (ch1
>> "A0") measured at the Digilent board pin, with 1.5cm probe ground to the
>> Digilent pin.
> 
> Does that go straight to the FPGA?
> 
> Is this what it's seeing?

Yes, the FPGA input is at the other end of about 2" of trace after the
pin where the signal was scoped.

>>> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
>>> the problem unless you've got _terrible_ ground problems.
>> Well if there are ground problems, they are out of my control, as this
>> is the signal at the pin on the Digilent board.  I would expect them to
>> have done a competent job.
>> I'm not sure, is there a history of people complaining about Digilent
>> board signal integrity problems?
> 
> No, as above this almost definitely isn't a problem.
> 
>>> This shows your design is still susceptible to asynchronous inputs toggling.
>> The important other fact is that if the drive impedance is made stiffer
>> (180->50ohms) and speed to the FPGA input increased (30->10ns) then the
>> glitches are no longer observed, even after an all night wait.
> 
> There could be a race condition internally which stops being a factor when
> you speed up the inputs.
> 
> Depending on your build, choice of pins etc this could be re-introduced at
> any point.

I find this less plausible than simply ground bounce.  Although at the
same time, I find it very new to have a problem with a 30ns rise/fall.

Can you explain a mechanism for such a race condition so I can think
about it better?

Regarding other things going on, there are the QEP outputs switching a
few ns after the clock switches.

There were several other asynchronous IOs going in and out, such as a
1MHz and 250kHz divided clock, coming from the 50MHz board clock (which
is async vs. the 288kHz qep_sim() clock causing the trouble.

> :-)

Indeed.

>>> Synchronise both(all) the inputs at the IO to the system clock then use those
>>> to look for falling or rising edges for your counter
>> Yeah, tried that.  Works.  I think I have things under control, with two
>> possible choices of path forward.
> 
> No, there's _only_ one path forward, synchronise your inputs.

Well that's what I've changed it to and it worked fine the first time.

> The input you're looking at is _reasonably_ fast, how fast is the internal clock
> you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this
> clock.

Well, the board clock is 50MHz.  That works fine.  Later I will
experiment with sending that into the on chip DCM/PLL/DLL thingy and see
what happens when I resync stuff at 100MHz, and 200MHz.

Of course, now the outputs of my qep_sim() have 20ns of
re-synchronization jitter relative to the 288kHz QEP "clock" input.

This is Ok in this situation because there are no other data flows
synchronous with the 288kHz that must interact with the output from the
FPGA.

But I can envision cases where this just can't be tolerated, and the
FPGA must be configured to count, divide, etc. external clocks and
produce outputs that are synchronous with the external clock.

It seems the FPGA designers are focussed on a world of data interfaces
where the one rule always applies.  But what if sub-ns jitter pulse
genration of frequency division relative to an external timebase is
required?   How to do that?  Can't be done unless you allow an isolated
clock domain.  This is a common need in scientific experiments, pulse
generators, laser control logic, etc.

What am I to do with those problems, design discrete logic again?

The whole point of an FPGA to me is that in a research environment, the
requirements change constantly, so flexible logic on an inflexible PCB
is necessary.  I take the expected needs today and say "oh they need a
few counters and gates, so multiply that by 100-1000 and in a few years
they will have chewed through half of the over-designed resources."
That much time I don't have to re-spin the hardware PCBs.  I love PLDs!
 Coupled with a decent CPU and one little platform can fill a thousand
roles.

That said, certainly what I've gathered at this point is that for
whatever clock is brought into the FPGA, that certainly shouldn't be
gated or muxed, unless perhaps it's done with resources designed for
that purpose, and there is comprehension on how to analyze the timing.



>> Thanks for the feedback.

Once again!




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

On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Nial Stewart wrote:
> > Depending on your build, choice of pins etc this could be re-introduced=
 at
> > any point.
>
> I find this less plausible than simply ground bounce. =A0Although at the
> same time, I find it very new to have a problem with a 30ns rise/fall.
>
> Can you explain a mechanism for such a race condition so I can think
> about it better?
>

FPGA logic is implemented with memory lookup tables.  Since your mux
logic has two clock inputs that are presumably running at different
frequencies there will be times when both of those inputs are changing
*close* to the same time and from the viewpoint of the memory device
that is encoding the mux logic might temporarily be outputting the
'wrong' value.  FPGA vendors can make the so that a single input
change to the memory will not cause a spurious output glitch but they
typically don't guarantee no glitches when two or more inputs change
simultaneously.  This may or may not be the failure mechanism in your
particular case here, but it is a mechanism that needs to be avoided.
This is also why one would want to sync the clocks first and then mux
them.

It's easy to think of the logic you write as being implemented by
gates, but that is not what is happening.  FPGA logic gets implemented
in lookup table memories.  Changing the address inputs can cause a
glitch on the output in certain cases.

Another situation would be if the two inputs are not asynchronous but
changing the relative timing of one with respect to the other changes
the behavior slightly (for better or worse).  As an example, any case
where you have a clock path that clocks some device and the clock then
goes through some delay and then gets used to clock some other device
that receives data input (directly or through logic) from the first
clocked device would be this type of situation.  If the delay through
the clock path is *long* and the delay through the data path is
*short* then the data can beat the clock to the downstream device.
This is a race condition.  In this case you can find that an apparent
'fix' (really a band-aid) can be any of the following:
- Re-routing until you get a long enough delay on the data path so
that the clock wins the race
- Put a big capacitor on the data line to attempt to slow the edge
down
- Re-route the clock on the board with wires so that the clock gets to
the downstream device sooner
- Spray the part with cold spray or heat up the device with hot air to
change the transistor characteristics just enough so that things
work...for a few seconds or minutes at best.

>
> Of course, now the outputs of my qep_sim() have 20ns of
> re-synchronization jitter relative to the 288kHz QEP "clock" input.
>
> This is Ok in this situation because there are no other data flows
> synchronous with the 288kHz that must interact with the output from the
> FPGA.
>
> But I can envision cases where this just can't be tolerated, and the
> FPGA must be configured to count, divide, etc. external clocks and
> produce outputs that are synchronous with the external clock.
>

In that situation you might use one of the other techniques that I
mentioned in your other posting:
- Replicate the logic, use the two clock inputs as real clocks and put
the mux on the back end outputs.
- Use a PLL that can switch over between multiple clock inputs

Which approach to use depends on what the actual conditions and
constraints you have to deal with in that situation.

> It seems the FPGA designers are focussed on a world of data interfaces
> where the one rule always applies. =A0

This isn't really limited to FPGAs.  Hark back to Digital Logic 101
class and recall that there are lots of ways to implement any logic
function:  memory devices, nand gates, nor gates, multiplexers.  Not
all approaches guarantee 'no glitch' performance.  What they guarantee
is that when the dust settles, the black box function appears to be
identical.

I'm not sure just what 'one rule' you're referring to, but the
important thing is that one must be somewhat aware of the actual
implementation and what pitfalls there can be with that type of
implementation so that one can avoid the pitfalls as best as possible.

> But what if sub-ns jitter pulse
> genration of frequency division relative to an external timebase is
> required? =A0 How to do that? =A0Can't be done unless you allow an isolat=
ed
> clock domain. =A0This is a common need in scientific experiments, pulse
> generators, laser control logic, etc.
>
> What am I to do with those problems, design discrete logic again?
>

Whether you need discrete logic would depend on the particular
problem, but the two approaches I mentioned earlier would likely
suffice for at least some of the problems.

>
> That said, certainly what I've gathered at this point is that for
> whatever clock is brought into the FPGA, that certainly shouldn't be
> gated or muxed, unless perhaps it's done with resources designed for
> that purpose, and there is comprehension on how to analyze the timing.
>

Then you've taken away the right lesson.

Kevin Jennings

>"KJ" <kkjennings@sbcglobal.net> wrote in message
>On May 18, 11:15 pm, "Mr.CRC" >wrote:
>> Nial Stewart wrote:
>> > Depending on your build, choice of pins etc this could be re-introduced 
>> > at
>> > any point.
>>
>> I find this less plausible than simply ground bounce. Although at the
>> same time, I find it very new to have a problem with a 30ns rise/fall.
>>
>> Can you explain a mechanism for such a race condition so I can think
>> about it better?
>
>FPGA logic is implemented with memory lookup tables.  Since your mux
>logic has two clock inputs that are presumably running at different
>frequencies there will be times when both of those inputs are changing
>*close* to the same time

I think KJ has spotted the problem.

Try using a BUFGMUX primitive instead of a LUT to MUX the clocks.