As you may recall, in an earlier blog from two weeks ago, I put some focus on switch de-bounce. I used a pretty standard methodology: (1) Detect a changing edge, (2) Start a delay timer, and (3) When the delay is done, read the switch value.
I've used this methodology before in discrete hardware and in software. It's not as absolute as I would like, but it works. I got some good feedback on that blog. Paul reminded us of the dangers of static and other risky-for-an-expensive-FPGA-chip issues, as well as the potential costs of using the FPGA for de-bounce as opposed to external hardware. Both of those make a lot of sense. The cost issue has a lot of facets. First, some FPGAs are really expensive. In other cases, the logic used to de-bounce might consume enough of the programmable fabric to push you up to a larger chip.
But I just have my FPGA development boards for the moment, so I'll continue to perform my switch de-bouncing activities in programmable fabric for a while. Just keep these factors in mind when you are designing permanent hardware.
All Programmable Planet member Rfindley pointed out that the common methodology, as I used it, can cause annoying delays for users. We might describe this as a balance between "switch settling time" and "user un-settling time." I certainly get annoyed at systems that have noticeable delays in key presses. His suggestion was to take the switch value at the first pulse. Then run the delay. That way, the user gets an instant result and most or all of the delay will be used up before the user tries a key press again. I like the idea, so I'm re-visiting de-bounce from that perspective.
I've returned to my Spartan 6 LX9 board so I can observe the signals with the ChipScope virtual logic analyzer. I've simplified my prior example for clarity, down to just one switch input and one LED output (the LED doesn't blink this time).
In a stable state, the value at the input of my de-bounce circuit matches that of the output. As soon as the input state changes, I will set the output value to match and start the delay timer. During the delay period, I will ignore any additional changes on the input. That seems straightforward enough, so here's the code for my leading-edge de-bounce function (click here to see a larger, more detailed version of this image).
Next page >