Regarding glitches,,,

[chocka]

Dear all,

I need a clarification regarding the glitches in data lines.
I am testing a FPGA prototype board by probing out the data line in
the debug pin of the board and i found that there are many glitches
occured in the data lines on viewing in logic analyser. The data line
is declared as "inout" in our glue logic.
I gave the data line to the 33ohm series termination resistor and
viewing the resistor output in the logic analyser. still the glitch is
coming. I also tried with 22 ohm series termination resistor.Still the
glitch is there...

Any ideas or suggestion please to remove the glitches......

Thanks in advance,

 

[David L. Jones]

Dear all,

I need a clarification regarding the glitches in data lines.
I am testing a FPGA prototype board by probing out the data line in
the debug pin of the board and i found that there are many glitches
occured in the data lines on viewing in logic analyser. The data line
is declared as "inout" in our glue logic.
I gave the data line to the 33ohm series termination resistor and
viewing the resistor output in the logic analyser. still the glitch is
coming. I also tried with 22 ohm series termination resistor.Still the
glitch is there...

Any ideas or suggestion please to remove the glitches......

Thanks in advance,

Next to impossible to debug without actually seeing the unit in
question, but there are general guidelines for stuff like this:
1) Use an oscilloscope to debug signal integrity stuff like this, not
a logic analyser. The scope will show you exactly what is really
there, logic analysers can easily lie to you.
2) Probing is very important, grounds can be critical. The higher
speed you go the more important and critical it becomes. What clock
and edge speeds are you working at?
3) PCB layout is often the culprit, have you checked you are using
proper high frequency design techniques?

Dave.

 

[David L. Jones]

Next to impossible to debug without actually seeing the unit in
question, but there are general guidelines for stuff like this:
1) Use an oscilloscope to debug signal integrity stuff like this, not
a logic analyser. The scope will show you exactly what is really
there, logic analysers can easily lie to you.
2) Probing is very important, grounds can be critical. The higher
speed you go the more important and critical it becomes. What clock
and edge speeds are you working at?
3) PCB layout is often the culprit, have you checked you are using
proper high frequency design techniques?

Dave.

I forgot to mention, it could easily be your FPGA design doing
something silly, might not have anything to do with signal integrity
etc.

Dave.

 

[neon]

you must first of all you must understand that a data analizer is not real time analysis an analog scope is needed to see for real glitches and usualy they are there because of speed and vcc not clean or daisy chain gnd loops. i never trusted data analizers because of that. an analog scope is needed try that.

 

[Robin]

Dear all,

I need a clarification regarding the glitches in data lines.
I am testing a FPGA prototype board by probing out the data line in
the debug pin of the board and i found that there are many glitches
occured in the data lines on viewing in logic analyser. The data line
is declared as "inout" in our glue logic.
I gave the data line to the 33ohm series termination resistor and
viewing the resistor output in the logic analyser. still the glitch is
coming. I also tried with 22 ohm series termination resistor.Still the
glitch is there...

Any ideas or suggestion please to remove the glitches......

Thanks in advance,

As the other poster says, use a scope instead. When you first turn it
on, turn the gain up to max ~ 1mV per div and then touch the input
with your finger. The display is showing a 60Hz (or 50Hz) waveform.
This is "glitching" And it is *not* even RF!

The higher the frequency the worse it will get and you are using
square waves!

You probably dislike the idea but if you could read up a little on
"ground plane" and "transmission line" and maybe "antenna" you would
have a distinct advantage to other digital-only chaps. And immediately
you will anticipate, avoid and/or minimise the problems you are
seeing.

It's better to avoid radiating energy than to try an absorb it in
termination but if you must then read up on "snubber" too.

Robin

 

[John Larkin]

Dear all,

I need a clarification regarding the glitches in data lines.
I am testing a FPGA prototype board by probing out the data line in
the debug pin of the board and i found that there are many glitches
occured in the data lines on viewing in logic analyser. The data line
is declared as "inout" in our glue logic.
I gave the data line to the 33ohm series termination resistor and
viewing the resistor output in the logic analyser. still the glitch is
coming. I also tried with 22 ohm series termination resistor.Still the
glitch is there...

Any ideas or suggestion please to remove the glitches......

Thanks in advance,

Data busses usually look terrible. They only have to be right at
specific times, and other times they can do anything.

John

 

[Joerg]

Data busses usually look terrible. They only have to be right at
specific times, and other times they can do anything.

Until you get to the EMC lab for a class B cert ....

 

[John Larkin]

Until you get to the EMC lab for a class B cert ....

If you hire sufficiently clever programmers, all the bus data will be
pseudorandom, spread-spectrum.

John

 

[martin griffith]

If you hire sufficiently clever programmers, all the bus data will be
pseudorandom, spread-spectrum.

John

or

William Gibson: "The future is already here, it just isn't evenly
distributed."



martin

 

[[email protected]]

Data busses usually look terrible. They only have to be right at
specific times, and other times they can do anything.

John

Chocka, John's post is the one you want to use. Now in theory, the
logic analyzer should be clocked and not seeing the glitches.

Bus glitches are a problem if you use programmable logic as a state
machine unless the data is run through a DFF, i.e. a master/slave set
up so that glitches are not propagated.

 

[krw]

If you hire sufficiently clever programmers, all the bus data will be
pseudorandom, spread-spectrum.

I found it pretty hard to find a data pattern or program that made
much of a difference. Data/address busses weren't the problems with
microprocessors. Clocks were the real nasties. There is a lot of
energy in microprocessor clocks and it's all aligned.

 

[neon]

if the glitches happens to be in the 50-60 hz zone then the Vcc needs more bypass if the gitches appear ramdom it is probably gnd loops . it is true at higher frequency the trouble is worst that is true if the data buss can carry those frequency to the inputs. glitches usualy appears as a consequence of some chip miss behaving and/or signals crunch. something is occurng somewhere else and you see the effects.