Scoping a glitch

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

What's the signal path to the FPGA?

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.

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

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.

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.

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

Explained above.

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?

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.

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

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

Does that go straight to the FPGA?

Is this what it's seeing?

causing

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

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.

:-)

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.

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

Nial

"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

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

causing

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.

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

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.

Once again!

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

at

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.

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.

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.

ed

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.

Then you've taken away the right lesson.

Kevin Jennings

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

Nial,

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

's causing

to

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.

ggling.

r e

hen

at

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.

se those

th two

nal clock

of this

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.

ed

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.

How would discrete logic be any different than an FPGA?

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

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

ced

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

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

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.

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.

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

Well considering:

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.

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.

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.

Yes. And so there is no disagreement.

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.

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.

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.

Key point. Got it many times over!

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.

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

Yes!

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

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.

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

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

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

[snip]

Here 'tis, from a 2001 c.a.f 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