Re: Spartan 3 Mapping Problem
- From: Rob Gaddi <rgaddi@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 09 May 2008 10:47:31 -0700
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
Marvin wrote:
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
On May 8, 4:44 pm, John_H <newsgr...@xxxxxxxxxxxxxxxx> wrote:Rob Gaddi wrote:
Three of them (including the one throwing the error and the one with the<snip>
DCM on it) are along the top of the chip (CLK4, CLK6, and CLK7 pins)
The fourth is down on the bottom on CLK0.
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
--
--
Rob Gaddi, Highland Technology
Email address is currently out of order
.
- References:
- Spartan 3 Mapping Problem
- From: Rob Gaddi
- Re: Spartan 3 Mapping Problem
- From: John_H
- Re: Spartan 3 Mapping Problem
- From: Rob Gaddi
- Re: Spartan 3 Mapping Problem
- From: John_H
- Re: Spartan 3 Mapping Problem
- From: Marvin
- Spartan 3 Mapping Problem
- Prev by Date: Re: Anyway to secure a Xilinx NGC file ?
- Next by Date: Re: Virtex XCV1000E-6FG860C
- Previous by thread: Re: Spartan 3 Mapping Problem
- Next by thread: Anyway to secure a Xilinx NGC file ?
- Index(es):
Relevant Pages
|