clock lines

You can have only 8 global clocks in each quadrant. There are 32 global resources available with right/left half clock pins that are different from the global clock pins available at the top and bottom of the device. You can have a design that uses all 32 on global resources.

If you exceed the 32 clocks (or 8 clocks within any one quadrant) then local routing can be used but the ability to properly place your part to meet setup/hold timing could be difficult. While general clock routing can be poor, if you synchronize your interface near the edge of the device, local routing can do a very reasonable job of keeping the setup/hold times in check. You might find good app notes on "local clocks" for those uses.

But you have to ask yourself: do you really need such a multitude of clocks?! All those asynchronous boundary crossings must be a MESS. You do know about multi-cycle paths and clock enables to work at an effective lower speed from a high speed clock, don't you?

I've never had more than 3 clocks in my designs that I can recall; there are designs that have a wide variety of interfaces, but I've never seen a "clock killer" app up close and personal.

Please work toward a design that uses clocks sparingly and you'll find the reduction in asynchronous interfaces worth the hassle.

- John_H

Alas the design is from somebody else so I don't have the option to re- write it. Thanks for the insight. I asked this question because it seems that for 1 net, XST is routing the signal from a DCM on the right side to a BUFGMUX on the bottom side. This is introducing additional delays that I would like to remove. I get the following issue during PAR which i am trying to resolve:

WARNING:Place:619 - This design either uses more than 8 clock buffers or uses more than 4 DCMs or has clock buffers locked to side-BUFG sites or has DCMs locked to side-DCM sites. The side-DCMs can drive only the BUFGs on the same side. Since side-BUFGs can drive only their half of the device and also exclude a global-BUFG from entering a clock region, it is necessary to partition the clock logic being driven by these clocks into different clock regions. It may be possible through Floorplanning all or just part of the logic being driven by the global clocks to achieve a legal placement for this design......... ...... ........................ WARNING:Place:620 - A DCM / BUFGCTRL clock component pair have been found that are not placed at an optimal DCM / BUFGCTRL site pair. The DCM component is locked to site and the corresponding BUFGCTRL component is locked to site . This will not allow the usage of the fast path between the DCM and the Clock buffer. You may want to analyze why this problem exists and correct it. This is not an error so processing will continue. Phase 4.2 (Checksum:99f58b) REAL time: 23 secs

Phase 5.30 ERROR:Place:848 - Automatic clock placement failed. Please attempt to analyze the global clocking required for this design and either lock the clock placement or area locate the logic driven by the clocks so that that the clocks may be placed in such a way that all logic driven by them may be routed. The main restriction on clock placement is that only one clock output signal for any competing Global / Side pair of clocks may enter any region. For further information see the "Quadrant Clock Routing" section in the Spartan3e Family Datasheet.

It's a pain i the butt :) Thanks for the help Amish

Hi, My two cents on the same issue,

I think you should consider using the Floor Planner. I have seen from prior experience that with more that 8 clocks the FPGA tools generally do not do a great job of routing. It helps a lot if you manually place all the BUFGs and DCMs using the Floor planner. It is not that difficult and does not take that much time. Once the DCMs and BUFGs locked, I think you would be able to resolve the problem.

In the longer run, I guess somehow you would have to figure a way to modify the design, because design with so many clocks is always a mess, and it throws up all kind so errors/warnings you try to implement it.

Have a great day.

-- Goli

I've had a similar problem recently, and it was fixed by LOCking the DCM to the higher side (of a V5) because the tool insisted on placing the DCM at the bottom, and use the BUFGMUX at the top.

YMMV w/xc3v

-P@

On Dec 6, 1:13 am, PatC wrote: [...]

This type of thing is certainly not restricted to V5. It happening to me back 5 years ago with V2's... well, something very close at least: the tools would randomly use non-dedicated routing from a clock input pin to the DCM. I took to putting a MAXDELAY of something like 1 ns on that net, which was easy to meet if it does the right thing, and impossible to meet if it didn't.

Have fun,

Marc