Regarding glitches,,,

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.

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

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

John

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

--
Regards, Joerg

http://www.analogconsultants.com

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

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.

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.

--
  Keith