Clock buffering in VirtexE FPGA

I assume in your board, push button is tied to some pin on FPGA. In constraints file (.UCF), specify that input PORT of your top level Verilog module, corresponding to your pushbutton SIGNAL, should be connected to specific input PIN of FPGA.

Example in constraints file NET "prtPUSH_BUTTON1" LOC = "P17";

You'll have to determine location LOC from board schematics. Sometimes they'll print it right on surface of the board. Look around pushbutton.

Hope that helps

This will work only if the prtPUSH_BUTTON1 is not an external clock. But if we are using the edge of this signal the tool will assume that it is a clock signal and assigns the BUFGP buffer for that this will conflict with the .ucf constarins and will give error at the time of mapping. We must use the .ucf as you suggested but then there should be a way to disable the clock buffereing at the time of synthesize.

hello Alfke.. will that be a problem if the push button switch does have a capacitor filter to reject switching noise. It have a filter with 10K resistor 10uF capacitor two 74V04 buffer stages and a diode protection at the input side. I am using this output to trigger a four bit counter. Will the bounce cause any damage to the sytem FPGA. Please advice me...

That's a very elaborate circuit for a humble push-button.

The device will be fine. Just please don't use this signal as a clock. If you want to count events on it, then sample it, edge-detect it, turn it into a single-cycle pulse in your system clock domain and use it as an enable to your four-bit counter. Anything else is asking for trouble.

-Ben-

Back to basics: (Experienced designers please ignore this). Any mechanical switch bounces, i.e. a switch closure is followed by a rapid sequence of open-close-open-close sequences (and a similar thing usually happens when the switch opens). This switch bounce can last for several milliseconds. If you have a single-pole-double-throw (SPDT) switch, you can easily circumvent the bounce, but with a simple switch you have to find a way to suppress it. Timing is the only differentiation between a single switch closure (with bounce) and an intentional sequence of switch operation. So you need a millisecond timing element to suppress the bounce, and milliseconds are hard to come by in a 100 MHz-clocked digital chip. But there is no alternative.

As I mentioned earlier, you can share one delay circuit between multiple switches, and you can also create the delay with external RC components, but you have to find some way to reliably differentiate between unavoidable bounce and intentional repetitive operation. Luckily, there are a few orders of magnitude of time in between. Peter Alfke

All that being said, you can use any input pin as a clock, not just the global clock inputs. This is O.K. as long as you don't have tight timing constraints for hold after the clock. In your case you probably don't want to do this, but you can always instantiate an input buffer and use the output of the IBUF as your clock source. This will be treated by the tools as any other internal signal made into a clock, so you shouldn't get the mapping errors (these come from an attempt to place an IBUFG in the non-global IOB). If you want you can also instantiate the BUFG after the IBUF, or if you're only clocking a single flip-flop for example and don't want a BUFG, you can attach a CLOCK_BUFFER constraint to the net (and set it to "none").

By the way, milliseconds may be "hard to come by", but not expensive in terms of CLB's. There were some very good posts on building long counters using SRL16's. see:

Which shows a very slick way to divide by 2^37 in just 3 slices.

Thanks Ben for your advice. Will do that way. One more doubt i have is :"the logic condition from an unconnected input pin will taken as '1' if i set the pin type to LVTTL in a virtex E device ???? Thank you

Thanks Aflek for your suggestion.

Thanks gabor for your suggestion...

If you use the "weak pull-up option". Peter Alfke

Thanks alfek for your suggestion.

Hi Ben,

I am just curious how does it work, what you've mentioned above. You sample a pushbutton signal that bounces, then edge-detect it and make sure that edge is one system clock wide. As a resullt you have several SYSTEM_CLK wide edges following push/release. Which one should be counted as actual push signal? Could you please explain it a bit more.

I've heard of another way to fight with switch bouncing. The trick lies in using a shift register to input pushbutton signal and an AND gate to detect all-ones case, which is equivalent to pushed button state.

Regards

Hi bobrics,

Actually, I wasn't giving advice on how to de-bounce a switch, but on how generally it's a bad idea to clock a register from something that isn't a clock. However, the circuit I (sort-of) described will work quite well if you sample at some very slow rate, 1ms or so. That is, the edge-detector should work on samples from the PBswitch line that are 1ms apart.

For level-detection, your AND-gate-and-shift-register circuit will also work, but again you should sample (i.e. shift) at a much lower rate than your system clock. This under-sampling is just a crude low-pass filter on the input signal.

I'd never bother with an external debounce circuit (not even RC) - in an FPGA, the simple digital filter is so close to being free it makes no difference... :-)

-Ben-

Sounds great.

Instead of a simple filter, undersampling is enough as it is, in fact, a crude LP filter. Is this correct?

If were actually using filter, what specs would you use? Cutoff at 1ms,

3dB point at .5ms?

Thanks Ben

Analyze the requirements. You must suppress the longest bounce, but you also want to react to the fastest possible legitimate operation. Establish these two times ( say

10 ms for longest bounce, and 100 ms for fastest human action) and put the cut-off somewhere in the middle. Peter Alfke