1. Home
  2. Field-Programmable Gate Arrays
  3. Spartan 3 Mapping Problem

Spartan 3 Mapping Problem

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 is placed at site . The IO component is placed at site . 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

Reply to
Rob Gaddi
Loading thread data ...

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

Reply to
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.

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

Reply to
Rob Gaddi

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

Reply to
John_H

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.

Marv> Rob Gaddi wrote:

Reply to
Marvin

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

Marv> Rob,

--

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

Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.