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. < PIN "reset_IBUF_BUFG.O" CLOCK_DEDICATED_ROUTE = FALSE; >
First a little background...
- The design was building and working fine.
- I was in the process of updating the project's SD Card controller to support SDHC cards.
- This error suddenly appeared even though I wasn't making any changes relating to the reset signal.
- Slowly backing out my changes I narrowed it down to the snippet of code shown below.
- 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.
- 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.