Scoping a glitch

[Mr.CRC]

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]

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

 

[Mr.CRC]

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

 

[Nial Stewart]

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

 

[Mr.CRC]

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

 

[Nial Stewart]

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

 

[Mike Treseler]

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

 

[Mr.CRC]

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

 

[KJ]

On May 18, 11:15 pm, "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.  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 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.  

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?   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?

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

 

[Andrew Holme]

"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.

 

[Mr.CRC]

Andrew Holme wrote:

"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.

No, I don't think it's the mux glitching since it does it even with one
of the inputs constant. I think I even removed the mux altogether and
it still had problems, until stiffening the source impedance.

I'm remaining convinced that it's ground bounce.

I tried a BUFGMUX and had a hell of a time with inability to implement
the design due to not being able to get the IO pins chosen to connect to
it. I was using right side GCLKn inputs on a Spartan 3E 500k.

I'm happy with the independent edge detectors providing clock enables,
which are muxed prior to sending to the qep_sim() which now clocks of
the board clock at 50MHz.


Now I have to go rework some amateurish resettable clock dividers...


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

 

[rickman]

On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:

Nial Stewart wrote:
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.

Nial,

I'm curious as to why you think this indicates it is not a ground
bounce problem?

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.

I don't follow. A 30 ns rise time is slow compared to the pulse
widths the FFs will clock at. The slow edge looks like a ramp and
with only a few tens of milivolts of ground noise imposed by the pins
and bond wires the voltage the internal input sees can glitch through
the threshold giving an unexpected clock edge.

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.

CRC,

So this is while the external clock is still slewing? If they are
high current or a lot of them, it can cause a problem with a slow
clock input.

I would also like to hear the details of the race condition.

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.

The more I think about this the less I agree. Logic always has
delays. The only issue if if the delay is too much. Then you need to
find a way to mitigate that delay or reduce it. I can't remember a
design where I couldn't just clock signals at the interface if that
was what I wanted to do.

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.

I have to say I'm not sure what "sub-ns jitter pulse genration of
frequency division relative to an external timebase" is exactly. So I
can't say what it requires in an FPGA. But no one has said you can't
use multiple clock domains. Your problem comes from a clock input
with an excessively slow rise/fall time. One easy fix is to not use
it as a clock, but as a clock enable by detecting the edge with
another clock. That effectively provides a low pass filter so the
fast glitches are removed.

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

How would discrete logic be any different than an FPGA?

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.

How is a PLD any different from an FPGA??? I'm very confused at this
point.

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.

Just to be clear running a clock through logic is not really an issue
for the clock. The only reason it is a bad thing is if you are using
the multiplexed clock for data on an IO pin. Then the internal delay
between the clock pin and the IO pin can be hard for the tools to
account for, mostly the variability in the delay. The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory and
is designed to not glitch from a single input changing state. In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.
As long as that clock is being used in a way such that the delay is
not important, then it will not cause problems... providing the select
line is not changing when your downstream logic is enabled. You don't
want to have splinter pulses on the clock mucking with your state
machines and counters.

If you think your problems here have anything to do with the fact that
you are using an FPGA, then you misunderstand what I have been telling
you. I hope I haven't given you any wrong information.

Rick

 

[rickman]

On May 19, 5:06 pm, "Andrew Holme" <a...@nospam.com> wrote:

"KJ" <kkjenni...@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.

That would be a band aid, if it even works. What makes you think this
is not noise in the ground connection imposing a spike on the slow
rise/fall time of the clock?

Rick

 

[KJ]

On May 20, 4:29 pm, rickman <gnu...@gmail.com> wrote:

On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net

Just to be clear running a clock through logic is not really an issue
for the clock.

This is not true. If the memory implementing the logic has a couple
of inputs changing together a glitch can occur. Based on what CRC
says this may not be his failure mode, but it is a failure caused by
"running a clock through logic".

The only reason it is a bad thing is if you are using
the multiplexed clock for data on an IO pin.

CRC's code does not clock in any data on an I/O pin...it simply clocks
a counter, all internal. So saying 'The *only* reason...' is not
correct.

The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory and
is designed to not glitch from a single input changing state.

A plausible explanation though for the rogue clock edge that advanced
CRC's counter at the falling edge is that the LUT structure did glitch
as a result of a single input changing. There are other plausible
explanations, my point is that I wouldn't rule out this as a
possiblity.

In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.

Not true. What about when both clocks happen to switch simultaneously
(or nearly so). Now you'll have two of the three inputs to the LUT
switching. Even if you were guaranteed no glitches with one input
changing, you're not guaranteed the same result with two.

Kevin Jennings

 

[Mr.CRC]

rickman wrote:

On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net
wrote:
CRC,

So this is while the external clock is still slewing? If they are
high current or a lot of them, it can cause a problem with a slow
clock input.

I would also like to hear the details of the race condition.


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.

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

The answer is "no" since the QEP output is switching *because* of the
erroneous count on the falling edge. Ie., QEP output switching here is
effect, not cause. So chalk this one up to my engaging mouth before
brain again.

What is going on is the asynchronous outputs from a pair of clock
dividers running off the board clock (which is async. to the QEP
mechanism) with outputs switching nearby to the troublemaker.

So a good experiment would be to scope those along with an incidence of
this glitch, and see if something else is actually observable switching
during the sensitive portion of the QEP clock edge.

But seriously, at this point this is all academic, because I have solved
the problem by following the good and applicable advice of everyone
here, by resynchronizing the QEP clock input and using the edge detects
as CEs.

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.

The more I think about this the less I agree. Logic always has
delays. The only issue if if the delay is too much. Then you need to
find a way to mitigate that delay or reduce it. I can't remember a
design where I couldn't just clock signals at the interface if that
was what I wanted to do.

Ok, but you do agree at this point that my QEP outputs now have 20ns of
jitter relative to the 288kHz signal which serves as their timebase, due
to the fact that the 288kHz has been re-synced to the board's 50MHz clock.

My point is simply that in the case where that 20ns of jitter is not
acceptable, then there would be two choices:

1. resynchronize the external clock with a higher frequency FPGA clock
such that the synchronization jitter is within tolerable limits, or

2. use the externally supplied clock directly, assuming that signal
integrity requirements were satisfied and that it was understood that
the logic driven by this clock constitutes a unique clock domain.

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.

I have to say I'm not sure what "sub-ns jitter pulse genration of
frequency division relative to an external timebase" is exactly. So I
can't say what it requires in an FPGA.

Simply taking in a clock, dividing it by N and spitting out the result.
Or using an external clock as the timebase to generate pulses of N
counts of that clock.

These are cases where synchronization jitter might not be tolerable,
precisely because it is necessary that the result signals must remain
*in* the clock domain of the external clock. Yes there will be delay,
but delay is delay, and jitter is jitter. The delay in this case would
be understood.

But no one has said you can't
use multiple clock domains.

Yes. And so there is no disagreement.

Your problem comes from a clock input
with an excessively slow rise/fall time. One easy fix is to not use
it as a clock, but as a clock enable by detecting the edge with
another clock. That effectively provides a low pass filter so the
fast glitches are removed.

Yes. Please recognize that sometimes I speak generally. Most of the
past few iterations of this discussion have been about generality, not
the original problem, which is solved and understood pretty well I think.

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

How would discrete logic be any different than an FPGA?

Well for one thing, it is composed of actual gates rather than LUTs, so
one can actually prove correctness of asynchronous designs if one
desires. Where, that seems to be impossible with LUTs.

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.

How is a PLD any different from an FPGA??? I'm very confused at this
point.

Just speaking generally again. I use the term "PLD" to mean the overall
category of programmable logic devices that includes PALs, GALs (both
mostly obsolete for my purposes) and more importantly CPLDs and FPGAs.

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.

Just to be clear running a clock through logic is not really an issue
for the clock. The only reason it is a bad thing is if you are using
the multiplexed clock for data on an IO pin. Then the internal delay
between the clock pin and the IO pin can be hard for the tools to
account for, mostly the variability in the delay.

Key point. Got it many times over!

The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory and
is designed to not glitch from a single input changing state.

Key point, of a more subtle variety. I've got it, but am still working
on a full understanding of this. I think another post is in order.

In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.

That would be in the case of a "glitch-free mux." I will make a new
post about this.

As long as that clock is being used in a way such that the delay is
not important, then it will not cause problems... providing the select
line is not changing when your downstream logic is enabled. You don't
want to have splinter pulses on the clock mucking with your state
machines and counters.

Yes!

If you think your problems here have anything to do with the fact that
you are using an FPGA, then you misunderstand what I have been telling
you. I hope I haven't given you any wrong information.

Rick

The only thing different about my FPGA is the fact that it is capable of
operating at frequencies several times higher than what I've dealt with
before.

Don't worry so much. Your input has been especially helpful, and I
think you are the one who's on target re: the real cause of my
glitch--ground bounce rather than the mux glitching. I'm pretty sure
this is proved at this point by the various observations that have been
made so far.

One nice thing about this group is that people have a much more
professional demeanor than at certain other less civil neighborhoods
(cough, cough, SED, cough cough).

I really appreciate this. I want to be able to have my kid peek over my
shoulder and not feel shame at the behavior of otherwise highly
intelligent folks.

Thanks to all!

I'll be back with more fun logic silliness in the future...


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

 

[KJ]

On May 20, 11:48 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:

Don't worry so much.  Your input has been especially helpful, and I
think you are the one who's on target re: the real cause of my
glitch--ground bounce rather than the mux glitching.  I'm pretty sure
this is proved at this point by the various observations that have been
made so far.

At this point, you don't appear to have enough to reasonably conclude
with high certainty on any cause (my opinion). The reality is that it
is pretty much impossible to prove much of anything since you can't
actually probe the offending signals so all you can do is hypothesize,
test and develop a preponderance of evidence that suggests some
particular cause more than other causes...and have to deal with the
fact that each new test can change dramatically the test conditions
since each new test could involve a new FPGA build.

Some tests that one could apply to see where things lead:
- Pull the unused clock input high. The failure rate should be
unchanged if caused by ground bounce.
- Pull the unused clock input low. The failure rate should decrease
if caused by ground bounce.
- Change the FPGA design to use just the one clock input. The failure
rate should be unchanged if caused by ground bounce. The failure rate
should decrease if caused by logic implementation glitch.
- Change the FPGA design so that only one clock input is used by the
one clock input still goes through a logic cell before being used as
it is in the original design. This will require some manual effort to
insure that this happens (see my reply to your other post regarding
mux and optomiziations). The failure rate should be the same as with
the original design.
- Change the FPGA design so that the mux and counters are replicated
many times. This will require preventing some optomizations so that
the mux and counters really do get replicated and not just a single
instance that gets fanned out. If ground bounce is the cause multiple
counters should glitch
- Change the FPGA design so that only the counters are replicated many
times. Again, ground bounce should cause multiple counters to glitch.
- Heat the device with a hair dryer or cool it with freeze spray.
Temperature will affect the threshold voltages but not the ground
bounce. If ground bounce is the cause then temperature should have
not effect the failure rate.

If you were to do all of these experiments (and others) you would
likely find that there are some mixed results, the result of one test
would seem to disprove one cause versus another. But each of these
experiments will inherently change more than 'just one thing' so you
will really have to dig into what other things changed in order to
determine what parameters really were controlled and which actually
varied. For example, adding additional counters clocked by the muxed
clock will change the capacitance seen by the logic that drives that
clock line through the FPGA. Increased capacitance makes it harder
for a glitch to occur since the capacitance will tend to squelch any
voltage change.

All of this though is just for those who want to experiment.
Practically for product design one tends to simply avoid the potholes
in the road and design around them. However, some folks do get the
time or the application is so critical that a deep understanding and
many types of experiments are justified.

One nice thing about this group is that people have a much more
professional demeanor than at certain other less civil neighborhoods
(cough, cough, SED, cough cough).

They are a rowdy crowd over there in SED...

Kevin Jennings

 

[rickman]

On May 20, 7:03 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On May 20, 4:29 pm, rickman <gnu...@gmail.com> wrote:

On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net

Just to be clear running a clock through logic is not really an issue
for the clock.

This is not true.  If the memory implementing the logic has a couple
of inputs changing together a glitch can occur.  Based on what CRC
says this may not be his failure mode, but it is a failure caused by
"running a clock through logic".

The only reason it is a bad thing is if you are using
the multiplexed clock for data on an IO pin.

CRC's code does not clock in any data on an I/O pin...it simply clocks
a counter, all internal.  So saying 'The *only* reason...' is not
correct.

The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory and
is designed to not glitch from a single input changing state.

A plausible explanation though for the rogue clock edge that advanced
CRC's counter at the falling edge is that the LUT structure did glitch
as a result of a single input changing.  There are other plausible
explanations, my point is that I wouldn't rule out this as a
possiblity.

In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.

Not true.  What about when both clocks happen to switch simultaneously
(or nearly so).  Now you'll have two of the three inputs to the LUT
switching.  Even if you were guaranteed no glitches with one input
changing, you're not guaranteed the same result with two.

Kevin Jennings

Kevin,

You are working with a model of the LUT that likely is not how they
are implemented. I was told by one of the experts at Xilinx, most
likely here in this group, that LUTs are designed to avoid this sort
of "race" glitch you are describing. The LUT mux is implemented with
pass transistors rather than gates and so one turning off before the
other turns on does not cause a glitch, it leaves a node undriven for
a brief moment and the capacitance holds the value. At least this is
what I remember, which may not be exactly what I was told. But it is
approximate.

I think this was Peter Alfke who told me this. Perhaps he is around
to verify that I remember it correctly.

As to CRC's problem, he has done some tests that pretty clearly show
the problem is ground noise perturbing a slow edge rate. He sped up
the edge and the problem went away.

Rick

 

[Allan Herriman]

On Sat, 21 May 2011 16:39:19 -0700, rickman wrote:

On May 20, 7:03 pm, KJ <kkjenni...@sbcglobal.net> wrote:
On May 20, 4:29 pm, rickman <gnu...@gmail.com> wrote:

On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net

Just to be clear running a clock through logic is not really an issue
for the clock.

This is not true.  If the memory implementing the logic has a couple of
inputs changing together a glitch can occur.  Based on what CRC says
this may not be his failure mode, but it is a failure caused by
"running a clock through logic".

The only reason it is a bad thing is if you are using the multiplexed
clock for data on an IO pin.

CRC's code does not clock in any data on an I/O pin...it simply clocks
a counter, all internal.  So saying 'The *only* reason...' is not
correct.

The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory
and is designed to not glitch from a single input changing state.

A plausible explanation though for the rogue clock edge that advanced
CRC's counter at the falling edge is that the LUT structure did glitch
as a result of a single input changing.  There are other plausible
explanations, my point is that I wouldn't rule out this as a
possiblity.

In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.

Not true.  What about when both clocks happen to switch simultaneously
(or nearly so).  Now you'll have two of the three inputs to the LUT
switching.  Even if you were guaranteed no glitches with one input
changing, you're not guaranteed the same result with two.

Kevin Jennings

Kevin,

You are working with a model of the LUT that likely is not how they are
implemented. I was told by one of the experts at Xilinx, most likely
here in this group, that LUTs are designed to avoid this sort of "race"
glitch you are describing. The LUT mux is implemented with pass
transistors rather than gates and so one turning off before the other
turns on does not cause a glitch, it leaves a node undriven for a brief
moment and the capacitance holds the value. At least this is what I
remember, which may not be exactly what I was told. But it is
approximate.

I think this was Peter Alfke who told me this. Perhaps he is around to
verify that I remember it correctly.

There was an appnote, dating from the XC3000 series parts. IIRC, the LUT
wouldn't generate glitches provided that at most one input toggled within
some small timing margin (which was in the order of the LUT delay).

Kevin's statement of the restrictions of a single-LUT mux are quite
valid. It's trivial to work around these using two ranks of LUTs though.

Regards,
Allan

 

[Allan Herriman]

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.

 

[rickman]

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?

Rick