1

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:
---------------

Speed Grade: -5

   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.

nanofarad
  • 18,062
  • 2
  • 47
  • 73
  • Are you using a DCM? I recommend you use it because help with clock issues, like skew or similar. – David Quiñones Jul 09 '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. – nanofarad Jul 09 '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 09 '15 at 15:57
  • @DavidQuiñones That clock is one that comes from an external device, through an IO (that is listed in the datasheet as GCLK but isn't routing properly through clock resources). – nanofarad Jul 09 '15 at 15:58
  • So, you have two external clocks, haven't you? – David Quiñones Jul 09 '15 at 16:00
  • Yes. I apologize for the poor wording, I was originally internal/external relative to the development board. – nanofarad Jul 09 '15 at 16:01
  • I recommend you to edit this point in the question to make easy to help you – David Quiñones Jul 09 '15 at 16:32
  • @DavidQuiñones Edited. Would you happen to have any idea how to get ISE to properly translate and map this design? I'm not very familiar with setting up pin constraints. – nanofarad Jul 09 '15 at 16:34
  • 1
    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 09 '15 at 16:52
  • For timing on the order of kilohertz suboptimal timing shouldnt be causing you state machine problems. Make sure your timing constraints (period) and input are setup correctly and that the design meets timing. If you still have a problem there is something else going on. – davidd Jul 09 '15 at 17:08
  • @davidd That might possibly be the cause of some of the issues. I had set absolutely no timing constraint for the suboptimally-routed clock input. I'll see if that fixes the root cause. – nanofarad Jul 09 '15 at 17:10
  • 1
    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 09 '15 at 17:38
  • @alex I hasn't even thought of that. I'm currently away from my computer with ise(currently on a mobile device), but I'll try that once I get the chance. – nanofarad Jul 09 '15 at 17:40

0 Answers0