Xilinx Error: Place 1018 message - xilinx

Question

I am using a Basys2 board to program a simple string detector to read patterns like "0101". I am using the Xilinix Design Suite 13.2 for this project. The .ucf file gives the following message.
ERROR:Place:1018 - A clock IOB / clock component pair have been found that are not
placed at an optimal clock IOB clock site pair.
The clock component <reset_IBUF_BUFG> is placed at site <BUFGMUX_X1Y1>.
The IO component <reset> is placed at site <IPAD73>.
Here's what my user constrains file looks like:
NET "x" LOC = "P11";# input switch
NET "reset" LOC = "K3"; # reset switch
NET "ck" LOC = "B8"; # clock
NET "b1" LOC = "A7"; # button 1
NET "b2" LOC = "M4"; # button 2
NET "z" LOC = "M5"; # output
One of the solutions I found online was to use this in the ucf:
CLOCK_DEDICATED_ROUTE = FALSE;
But unfortunately this didn't work for me. I'd appreciate any help with this problem.

Answer 1

The message appears to imply that your reset is being detected as a clock signal. That should be worrying - do you have processes which are sensitive to the edge of the reset signal?
You should (until you really know what you're doing) only use a couple of forms of process.
Asynchronous reset
process (clk, reset)
begin
if reset = '1' then
-- async reset stuff
elsif rising_edge(clk) then
-- sync stuff
end if;
end process;
Synchronous reset
process (clk)
begin
if reset = '1' then
--sync reset stuff
else
-- other sync stuff
end if;
end process;
Also, be careful - you still need to release the reset signal to these processes synchronously.
Here's a good read on various reset strategies:
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
Finally, using CLOCK_DEDICATED_ROUTE = FALSE; is another no-no for almost every situation.

Answer 2

In my case, I got that inscrutable error message because I mistyped:
always #(clk) begin
if (rst) begin
...
instead of
always #(posedge clk) begin
if (rst) begin
...
Apparently since it wasn't using the edge of clk, rst was now being treated like a clock and messing up routing.
I know this is an old question but I just hit this problem using ISE and Spartan 6; hopefully this answer will help someone (most likely me 6 months from now).