# Xilinx Place Error 1136 - This design contains a global buffer instance that is driving the following non-clock load pins

I'm hoping someone can explain in simple terms why I might be getting this error from the Xilinx map tool:

ERROR:Place:1136 - This design contains a global buffer instance,
<reset_IBUF_BUFG>, driving the net, <reset_IBUF_BUFG>, that is driving the
following (first 30) non-clock load pins.
This is not a recommended design practice in Spartan-6 due to limitations in
the global routing that may cause excessive delay, skew or unroutable
situations.  It is recommended to only use a BUFG resource to drive clock
loads. If you wish to override this recommendation, you may use the
CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
this message to a WARNING and allow your design to continue.
< PIN "reset_IBUF_BUFG.O" CLOCK_DEDICATED_ROUTE = FALSE; >


First a little background...

1. The design was building and working fine.
2. I was in the process of updating the project's SD Card controller to support SDHC cards.
3. This error suddenly appeared even though I wasn't making any changes relating to the reset signal.
4. Slowly backing out my changes I narrowed it down to the snippet of code shown below.
5. Thinking this might be related to the larger project I was working on, extracted the SD Card Controller entity to a separate test project. I get the same error there.
6. I don't know where the IBUF_BUFG on the reset line is coming from - it's certainly not something I'm explicitly creating. I do however have the reset signal driving a coregen'd clock core.

Here's the snippet of code that seems to trigger the error:

when RX_BITS_FINISHED =>
if do_deselect='1' then
bit_counter := 2;
state <= DESELECT;
else
state <= return_state;
end if;


If I comment out the above, the error goes away. Everything referenced here are either variables or signals private to the module. The when block is inside a process driven by clock and reset signals. Nothing special here but the full source of the component can be seen here with the above snippet near the bottom.

Anyway... I looked up the error and came across this Xilinx answer:

which might explain things for some, but not to me. I've read the suggested solution and worked through it but I'm concerned I'm just masking a more fundamental problem with my design.

I don't understand what's happening here and need someone to explain it so an amateur/learner can understand it.

• Have you tried making the reset synchronous under the clock? I don't know if it makes sense in your design but that is my guess for the root cause of your problem. – Lincoln Apr 11 '17 at 1:02
• Is this ISE or Vivado? It should write out why and where it generated the BUFG. How is the PLL related to your design? – Paebbels Apr 11 '17 at 5:46
• @Lincoln - pretty sure all the resets are synchronous but will double check. (ie: all reset handling is handled inside an on(clock,reset) process) – Brad Robinson Apr 11 '17 at 7:19
• @Paebbels - it's ISE for Spartan 6. The PLL is part of the coregen'd clock core. Where would I check why the BUFG is generated - is that part of XST's .syr report or somewhere else? – Brad Robinson Apr 11 '17 at 7:20
• This error is likely caused by a chain of events. The snippet you show is just the final drop. What version of which tool are you using? First thing I would advice is: use synchronous resets. Asynchronous resets sometimes add logic in the clock path. But if you want to keep the asynchronous reset: How are you driving it? Is de-assertion properly synchronized? – JHBonarius Apr 11 '17 at 11:02