Clock buffering in VirtexE FPGA

I am new to this group and new to FPGA. I am working with XCV2000E
fpga. Tool i am using for synthesiz is Xilinx ISE 6.2i. I am working
with logic module provided by ARM. I need to interface a push button
switch provided in the board.
But whenever i use the edge of this signal for triggering in the code(i
am using verilog) xilinx tool assumes it as a clock signal and ties it
to default pins provided in the FPGA. But this pin is difffernt from
the push button input. How can i reassign the input to the push button
switch. How can i disable the clock bufferenig in the tool.
One method i found is change in the code. insted of directly clocking
with push button i passed it through an and gate. This removed buffring
of the push button.
Eg:
insted of
always @(posedge pbut)
i used
assign temp_clk = pbut & pbut_enable;
always @(posedge temp_clk)

where pbut_enable is an external signal and assigned LVTTL type to it
(this i hope when unconnected will keep the pbut_enable at "high"
state").
Will this method work. Anyway i want to know about clock disabling in
the tool
Hope you people will help me. Thank you.

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.

Using a push button as a clock input to modern fast logic is an
invitation to disaster. The contact bounce will play havoc with your
design.
Peter Alfke

vssumesh wrote:
> 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...

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

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

> Will the bounce cause any damage to the sytem FPGA. Please advice me...

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

Peter Alfke wrote:
> 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:

http://groups-beta.google.com/group/comp.arch.fpga/msg/ce00d2e88b7865b8?hl=en

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.