What is the difference between debounce and deglitch in FPGA

All,

I'm trying to understand the difference between a deglitch and debounce circuit. I saw something here, but I've never seen a debounce that doesn't reset count on a change...seems like what sh1 was implying is a debounce is a moving average.

Maybe someone here can help me with the semantics of debounce vs deglitch because as far as I can identify they are both used to confirm stability for a duration.

I'd probably implement them as described below.

1. For a deglitch I'd use a shift register and bitwise reduction-AND the sr to confirm stability is true for shift register length. (short and spurious)
2. For a debounce I'd probably implement a count, reseting each time there is a change. Once stability is true for count length I confirm change. (Long and like PWM)

Appreciate anyones input.

Regards,

Okay so the implementation I wrote there will cause deglitch to freak out on a small bounce down. It's more a suppression of a state than an resilience to change.

Fix to deglitch method so that it behaves like debounce!!

I am not a FPGA designer.

My understanding debounce is generally used to handle mechanical button
bounce due to inertia of contacts and their bounce, typically in the 10's of mS
area. Note I have worked with Mechanical switches who exhibited several
hundred mS of bounce before the settled.

Deglitch is to handle signal paths that have problems meeting setup and hold time.
Using clock synch circuits to rectify these issues.


Regards, Dana.

I'd say, both methods are probably behaving identically. Any indications that it is not?

FvM said:

I'd say, both methods are probably behaving identically. Any indications that it is not?

Click to expand...

This is a tad thin but I see two different time domain issues, debounce a"process"
delay problem, whereas deglitch a gate level delay problem. But to you point delay
solves both.

Regards, Dana.

Both solutions are clocked - timing is set by clock cycle not gate delay.

Glitches are usually considered to be gate sized delays and can be corrected with simple gate delay line filtering.

Debounce is usually a mechanical problem where contacts don't switch smoothly due to "bouncing" when the contact moves to a closed position and bounces off the contact. This type of "glitch" is in the 10s of ms or more as previously mentioned. If you could find gates that have 10s of mS of delay you could use simple gate delay filtering and get rid of a debounce "glitch", but that is impractical as there aren't any 10ms delay gates.

Instead for a debounce circuit the counter method is used and resetting the counter every time a transition occurs ensures that the input is stable for whatever the debounce duration counter is set to before passing on the filtered signal.

The are both effectively filters but the magnitude of the issue is fatr different between the two types of designs.

I assume that the question is about external signals going into the FPGA. Glitches originating inside the FPGA (race conditions) are something else, and should be avoided instead of "deglitched".

It is important to understand the difference between debounce and deglitch for external signals, because there is a simple debounce solution that can't handle glitches!

Debounce = Handles glitches/noise/garbage that only happens when there really is a change going on for the external signal. This is always needed for signals controlled by mechanical switches.

Deglitch = Handles glitches/noise/garbage that can happen at any time. This is related to EMC, not mechanical switches.

It is possible to handle both in the same circuit, but that is more complicated than a debounce-only circuit.

The simplest possible debounce solution is to only sample the input with a time interval longer than the "bounce" time.
If one sample is made during the "garbage" related to a valid transition, it doesn't matter if it is '0' or '1'. The next sample will be correct
(it doesn't matter if we sample the sequence 00011111 or 00001111).
However, "random" glitches can't be handled, because we don't want to sample 000010000.

It can be a good idea to put a deglitch circuit after the simple debounce circuit.

What I've implemented is at https://github.com/w-tr/digital_filters/tree/master/lowpass/rtl

From my understanding, #7, wouldn't it be better to have -raw signal -> deglitch -> debounce (basically the otherway round?)

wesleytaylor said:

What I've implemented is at https://github.com/w-tr/digital_filters/tree/master/lowpass/rtl

From my understanding, #7, wouldn't it be better to have -raw signal -> deglitch -> debounce (basically the otherway round?)

Click to expand...

If you do the deglich processing first, it will be more complicated (how long can a glitch be?), but it can probably also handle the debounce at the same time.

Some alternatives:
(1) Raw signal -> complicated deglitch and debounce -> filtered signal
(2) Raw signal -> simple debounce -> filtered signal (normally OK for a mechanical switch)
(3) Raw signal -> simple debounce -> simple deglitch -> filtered signal

"complicated deglitch and debounce" (example) = a counter counting up or down depending on the input value
"simple debounce" (example) = sample the input signal with a 20-50 ms interval or so.
"simple deglitch" = only change the output when there are 2 or 3 identical samples in a row

Maybe a counter is needed to generate the 20-50 ms sample pulse for the "simple debounce",
but the same signal can be used by all "simple debounce" inputs in the design.
If the "complicated deglitch and debounce" is implemented with a counter, one counter per input is needed.