Spartan 3 Mapping Problem

[Rob Gaddi]

So, I'm busily poking around at a Spartan 3 design, and can't get my
latest iteration of things to build properly. I've got all my pin
locations defined, but make no recommendations to the tools as to which
clocking resources to use how and where. Yet when I try to map the
design, I get:

---
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 <INST_PLL/BUF10/BUFGMUX> is placed at site <BUFGMUX2>. The IO
component <EXT_10_MHZ> is placed at site <A11>. 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 "EXT_10_MHZ" CLOCK_DEDICATED_ROUTE = FALSE; >
---

Now it seems to me that, if I'm letting MAP pick which clock buffers
should do what where, that I'm the last guy in the world it should be
complaining to about not liking the decisions that get made.

For reference: my clocking situation is as follows:

8MHz --O----+------BUFGCE>--------------8 MHz clock
\----------data pins

10MHz --O----+------BUFGCE>--------------10 MHz clock
\----------data pins

20MHz --O----BUFG>------+----------------20 MHz clock
\--DCM>--BUFG>---40 MHz clock

128MHz -O----BUFG>-----------------------128 MHz clock

which all gives me an XST clock report of:
----------------+----------------------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
----------------+----------------------------------------+-------+
CLK128 | IBUFG+BUFG | 7854 |
CLK20 | IBUFG+BUFG | 2058 |
CLK20 | DCM_INST:CLK2X | 59 |
BOARDSYNC_IN | IBUF+BUFGCE | 4 |
EXT_10_MHZ | IBUF+BUFGCE | 5 |
----------------+----------------------------------------+-------+

So, I've got only one DCM used on a chip with 4, only 5 BUFGs used on a
chip with 8, and yet somehow I can't get everything to fit nicely. Any
suggestions on what's going on/how to fix it?

Thanks,
Rob

--
Rob Gaddi, Highland Technology
Email address is currently out of order

[John_H]

Rob Gaddi wrote:
<snip>

> For reference: my clocking situation is as follows:
>
> 8MHz --O----+------BUFGCE>--------------8 MHz clock
> \----------data pins
>
> 10MHz --O----+------BUFGCE>--------------10 MHz clock
> \----------data pins
>
> 20MHz --O----BUFG>------+----------------20 MHz clock
> \--DCM>--BUFG>---40 MHz clock
>
> 128MHz -O----BUFG>-----------------------128 MHz clock
>
> which all gives me an XST clock report of:
> ----------------+----------------------------------------+-------+
> Clock Signal | Clock buffer(FF name) | Load |
> ----------------+----------------------------------------+-------+
> CLK128 | IBUFG+BUFG | 7854 |
> CLK20 | IBUFG+BUFG | 2058 |
> CLK20 | DCM_INST:CLK2X | 59 |
> BOARDSYNC_IN | IBUF+BUFGCE | 4 |
> EXT_10_MHZ | IBUF+BUFGCE | 5 |
> ----------------+----------------------------------------+-------+
>
> So, I've got only one DCM used on a chip with 4, only 5 BUFGs used on a
> chip with 8, and yet somehow I can't get everything to fit nicely. Any
> suggestions on what's going on/how to fix it?
>
> Thanks,
> Rob

<snip>

Are all your clock inputs defined as one edge of the chip? I'd
suggest using FPGA Editor to delve into your chip to understand where
the signals are easily routed from. It may be that you *must* go from
one side to the other to use the pins you've chosen. I recall some
suboptimal choices in the Spartan-2s that made me choose manually
where my clock buffers and DCMs would be so I haven't come across the
error you have lately.

- John_H

[Rob Gaddi]

John_H wrote:
>
> Are all your clock inputs defined as one edge of the chip? I'd
> suggest using FPGA Editor to delve into your chip to understand where
> the signals are easily routed from. It may be that you *must* go from
> one side to the other to use the pins you've chosen. I recall some
> suboptimal choices in the Spartan-2s that made me choose manually
> where my clock buffers and DCMs would be so I haven't come across the
> error you have lately.
>
> - John_H

Three of them (including the one throwing the error and the one with the
DCM on it) are along the top of the chip (CLK4, CLK6, and CLK7 pins)
The fourth is down on the bottom on CLK0.

[John_H]

Rob Gaddi wrote:
>
> Three of them (including the one throwing the error and the one with the
> DCM on it) are along the top of the chip (CLK4, CLK6, and CLK7 pins)
> The fourth is down on the bottom on CLK0.

<snip>

So are you going to look into the FPGA Editor view like I suggested?

Another question for you to ponder much more than to answer here: did
you instantiate the BUFGMUX primitives or are those coming from your
synthesizer? It may be that you need to hook up the I1 channel rather
than the I0 on one or two of your BUFGMUXs to work with the routing
from the clock pins to the buffers... which is why I suggested looking
at the details of the part in FPGA Editor.

- John_H

[Marvin]

Rob,

Did you LOC your IOs down? Each BUFG has a dedicated IO that should
be used. A list of these IO locations are available from the Spartan
3 User Guide. If you LOC the IO to one of the non-dedicated IOs, this
error message will appear.

Marvin

[Rob Gaddi]

Each of the clock signals is LOCed to a dedicated clock IO pin.

So I went in with the FPGA editor to do a little more investigation, and
it sure looked like I could just pipe the clock signals from their
points of origin to the proper BUFG with no problems. I tried LOCing
them down in the UCF and rebuilding, and came up with the excitingly new
error of:

---
ERROR:Place:1023 - A global clock component <INST_PLL/BUF10/BUFGMUX>
configured as a selectable mux is placed in site BUFGMUX6. This
configuration requires that the global clock site BUFGMUX7 either be
empty or contain a global buffer or mux with the inputs IN0 and IN1
either not driven by a signal or driven by the same signals as the
original muxes IN1 and IN0 pins respectively in order to route up both
of the inputs. In other words the input signal for IN0 on one buffer
must be the same as the input signal driving IN1 on the other buffer (or
one of them must not be driven) to place the two buffers in the paired
sites. The site BUFGMUX7 has the global buffer <io_clk_BUFG> placed
there. This design is unroutable.
---

That finally gave me enough information to figure it out.

In looking a little more closely at it, the problem seems to be the use
of a BUFGCE on the 10 MHz clock. It looks like the Spartan requires
adjacent pairs of BUFGMUXes to share the same two input clocks. Trying
to make that pair accept CLK20, CLK10, and GLOBAL_LOGIC_0 as potential
input clocks was too much for it. Since the logic on the CLK10 path had
to be runt-resistant anyhow to handle the case where the 10 MHz clock
was suddenly disconnected, I can just switch that over to a regular BUFG
rather than a BUFGCE, and live with the runts when the clock is suddenly
connected too.

Thanks for the help, guys.
-- Rob

--