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.
< PIN: clock_core1/pll_base_inst/PLL_ADV.RST; >
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.

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:

    if do_deselect='1' then
        bit_counter := 2;
        state <= DESELECT;
        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.

  • \$\begingroup\$ 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. \$\endgroup\$ – Lincoln Apr 11 '17 at 1:02
  • \$\begingroup\$ Is this ISE or Vivado? It should write out why and where it generated the BUFG. How is the PLL related to your design? \$\endgroup\$ – Paebbels Apr 11 '17 at 5:46
  • \$\begingroup\$ @Lincoln - pretty sure all the resets are synchronous but will double check. (ie: all reset handling is handled inside an on(clock,reset) process) \$\endgroup\$ – Brad Robinson Apr 11 '17 at 7:19
  • \$\begingroup\$ @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? \$\endgroup\$ – Brad Robinson Apr 11 '17 at 7:20
  • \$\begingroup\$ 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? \$\endgroup\$ – JHBonarius Apr 11 '17 at 11:02

From ISE, under 'User Constraints', open 'I/O Pin Planning (PlanAhead) - Post-Synthesis'. This should open a schematic where you can follow the signal that drives the PLL reset around your design. Double click a net or component to show all elements that it connects to. Does this signal lead to any register clocks or latch gates? If so you should be able to see from the hierarchy which particular piece of code is causing clock inference.

My bet is that you have inadvertently created a latch by specifying an asynchronous load in one of your reset cases.

  • \$\begingroup\$ thanks I'll look into that. Sounds like I can learn something that way. \$\endgroup\$ – Brad Robinson Apr 11 '17 at 23:29

Follow up - switching all the resets to synchronous fixed this issue.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.