switch debounce


Recommended Posts

Hi all,

I am trying to solve the switch debounce problem in Hamster's book, chapter 17.

Hamster suggestion is to solve it using some code lines in the FSM.

My guess is that I need to ignore returning to previous state cases, for example if I'm moving from "00000001" state to "00000011"; when in "00000011", I will do nothing for the input "00000001", which can be a switch bounce.

I haven't tested it yet, but it sounds sloppy, mostly because it doesn't pay attention to the amount of time of the bouncing, Is this the solution?

I found on the web some switch debonce modules in vhdl which involve counter, but they where a lot harder to implement...

can anyone share his solution or suggest what is the best way to deal with switch bounce with the tools acquired up to chapter 17?



Link to comment
Share on other sites

I'd use something along the following lines.


input wire switch;

reg state = 0;

reg [19:0] count = -1;              // all bits on, maximum value

always @(posedge clk) begin

count <= count - 1; 

case (state ^ switch)

0: count <= -1;                     // state and switch agree; reset counter (takes priority over prev. assignment to count)

1: if (count == 0) state <= !state; // state and switch disagree, counter has expired




It's untested, please exercise caution in case you're designing an open-source pacemaker with a button :)

Link to comment
Share on other sites

Hi Nadav,


It looks like you have got to the heart of the problem - "it doesn't pay attention to the amount of time of the bouncing". That is the key observation - to do this properly you need something that tracks the passage of time because switch bounce is time dependant.


Here's a few ideas....


a) You can make the FSM work in both directions (e.g. If you allow it to go from "00000001" to "00000101", then you from state "00000101" you can go back to "00000001" without causing an error. Completely "timeless" in that as you point out, you can come back an hour later and run the FSM backwards from the desired state.


b ) You can introduce extra 'debounce' states, to prevent the FSM from going backwards further than one step. e.g. for  "00000001" to "00000101" you might have  "state00000001", "state00000101" and "state00000101debounce". If in state00000101 and you see the switches change to 00000001 you go into state00000101debounce and stay there until the switches bounce back to 00000101, or you see something other than 00000001, in which case the user got the sequence wrong.


c) You can debounce each switch, using something similar to OffRoad's pacemaker-ready code :). Doing this eight times will be relatively resource hungry but it will give great results.


d) You can debounce all the switches as one (e.g. debounce the "switches" vector, not the individual signals). This is a little ugly as the state changes of any one switch restarts the debounce period for all eight switches, giving unwanted coupling. Not a problem in this design, but could be if you use the same code for a different purpose. For example, if these were four pairs of signals from the rotary encoders on a robot's wheels then counts could be missed - a stationary wheel's encoder could be bouncing between "01" and "11", masking that the other wheels are actually moving.


e) You can 'debounce' the FSM state signal. To do this reset a counter when the FSM state changes, and only allow it to change state again once that counter has expired. This is pretty neat as it logically says something  "I can change state at most only once every 'n' clock cycles".


f) We have a problem in that the FSM can respond a lot quicker than a switch can (e..g  the FSM runs at 31ns vs a few ms). You could ignore bouncing altogether if the FSM is updated once every 1/4th of a second or so. The worst that can happen is that the state change will be delayed by 1/4th of a second,,,


There is most likely another dozen ways to address this all of them with their merits - and then you have to decide just how long you think the switch to bounce for!

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.