# Why am I unable to use a pin marked as GCLK in the datasheet as a clock resource, when an identically-marked pin works, on a Spartan-3E?

I am trying to create a sequential circuit on a development board with a Xilinx Spartan3E XC3S500E in an FT256 package. The board has a 50MHz crystal oscillator connected to pin B8, which is marked as an input and GCLK in the datasheet. Additionally, there are more IO pins that are marked as GCLK, that are broken out (and accessible for me to use), including A9 and C8 (which I've specifically tried to use).

When I try to use the pin B8 as a clock input, everything synthesizes normally, without any manual clock buffers or IBUFG primitives. However, I also need to be able to clock my circuit using a different external clock connected to a different pin (as the crystal is permanently soldered on), at a far lower frequency (on the order of kilohertz). Previously, I had simply disregarded the warnings about suboptimal clock routing, using the constraint CLOCK_DEDICATED_ROUTE = false. However, it appears that the circuit's FSM was ending up in an invalid state due to poor clock routing. (skew, possibly?) In order to determine whether that was the case or not, I am currently trying to use a clock with the optimal routing using the dedicated clock routes.

When I constrain my clock input to a pin such as A9 (labeled as I/O and a GCLK), I get errors during the Map stage:

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 <BUFGCE_inst/BUFGMUX> is placed at site <BUFGMUX_X2Y10>. The IO component <CLK_INPUT_PIN> is placed at site <C8>. This will not allow the use of the fast path between the IO and the Clock buffer. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule.
< NET "CLK_INPUT_PIN" CLOCK_DEDICATED_ROUTE = FALSE; >

I was originally running this clock to a BUFGCE to use a clock-enable. I have also tried both removing the BUFGCE and connecting the clock directly to the rest of my design, as well as adding an IBUFG. When I look at the RTL schematic, the clock buffer is shown as expected.

I have also tried modifying the constraints on the pin in the UCF file. Originally, the pin was configured with a LOC, slew rate, and drive strength. I tried modifying the constraints to only specify LOC, which did not help, and I also attempted to re-use the constraints given on the working clock pin, with a different location.

Synthesis final report:

=========================================================================
*                            Final Report                               *
=========================================================================

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
CLK_INPUT_PIN                      | IBUFG+BUFGCE           | 79    |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design

Timing Summary:
---------------

Minimum period: 9.194ns (Maximum Frequency: 108.772MHz)
Minimum input arrival time before clock: No path found
Maximum output required time after clock: 7.258ns
Maximum combinational path delay: 7.683ns


If someone could suggest a working solution or shed some more light on this issue, that would be great.

Edit regarding DCMs: I checked the datasheet in preparation to add a DCM to the input that wasn't working. This doesn't appear to be doable since the datasheet/implementation guide specifies that 5MHz in the minimum frequency.

• Are you using a DCM? I recommend you use it because help with clock issues, like skew or similar. – David Quiñones Jul 9 '15 at 15:53
• @David I am not currently using a dcm. Are you suggesting using it to handle the external clock that currently isn't routing, the crystal clock currently without issues, or both? I have no skew or other issues with the onboard 50MHz crystal. – Andrey Akhmetov Jul 9 '15 at 15:55
• Other question. What do you mean with "I also need to be able to clock my circuit externally, at a far lower frequency (on the order of kilohertz)" Are you using the FPGA to generate this clock. There are IOs related to this low speed clock? – David Quiñones Jul 9 '15 at 15:57
• Slew rate and drive strength only apply to output pins. Anyway, I presume that the error message and final report came from different synthesis runs. What did you change in between, exactly, to get synthesis to complete? – alex.forencich Jul 9 '15 at 16:52
• Another option would be to clock the whole thing on the fast clock, then use the fast clock to generate clock enable pulses from the slow clock. This would eliminate any clock routing issues with the slow clock. – alex.forencich Jul 9 '15 at 17:38