Re: Scoping a glitch
- From: "Arie de Muynck" <nospam@xxxxxxxxxx>
- Date: Tue, 17 May 2011 22:06:16 +0200
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@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:iqss1601vk@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
SuSE 10.3 Linux 2.6.22.17
.
- Follow-Ups:
- Re: Scoping a glitch
- From: Mr.CRC
- Re: Scoping a glitch
- References:
- Scoping a glitch
- From: Mr.CRC
- Scoping a glitch
- Prev by Date: Re: Counter clocks on both edges sometimes, but not when different IO pin is used
- Next by Date: Re: Scoping a glitch
- Previous by thread: Scoping a glitch
- Next by thread: Re: Scoping a glitch
- Index(es):
Relevant Pages
|