UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 23480

8.1i Virtex-4 PAR - "ERROR:Place:467 - Automatic clock placement failed."

Description

Keywords: placer, DCM, region

My design fails during placement with an error message similar to the following:

"Phase 4.30
ERROR:Place:467 - 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 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 8 of 32 clocks sourced by Global buffers may enter a region. For further information, see the "Global clocks" section in the Virtex-4 Hand-Book."

What is automatic clock placement, and what can I do to correct this problem?

Solution

1

The automatic clock placer exists because of the need to manage the routing restrictions of the global clocks. Each clock region has global routing resources for up to eight clock domains in a Virtex-4 device or up to ten in a Virtex-5 device. The clock placer has to first choose locations for each clock component (Clock IOBs, Clock Buffers and DCMs) and then automatically control clock region usage using area constraints on the clock loads. The clock placer prints a rather verbose report containing a distribution of the clock domains by clock region and a list of the constraints that were used to achieve that distribution. If the clock placement algorithms fail to find a solution, the "ERROR:Place:467" error occurs. The clock distribution report will still be printed to provide insight into the failure.

In ISE version 8.1i, there was a known problem that the automatic clock placement algorithms did not always constrain DCMs well because the DCM placement is fixed after the first phase. DCMs driven by BUFGMUXs will use one of the eight global resources in a clock region, like any other clock load, and must be accounted for. Clock placement failures can often be avoided by locking the DCMs to sites in clock regions that do not have inherently high global resource utilization. Avoid clock regions that have a lot of fixed clock usage due to locked I/O, PPCs, etc.

In ISE 8.2i, the clock placer began printing a report of the clock region utilization so that the congested clock regions can be identified. It also provides clock region constraints in UCF syntax that will reproduce the original placement. Typically, a failed placement is very close to a valid solution and can be manually edited to correct the over-utilized clock regions.

In 8.2isp1, the clock placer handles DCMs more intelligently and it is less likely that they will need to be constrained.

2

If the clock placer fails to find a solution, the distribution report will allow you to identify the clock regions that are over utilized. Once you have identified the problem clock region(s), it is possible to take the constraints generated by the automatic placement attempt and tweak them to alleviate the congested clock regions. Check for the following issues:

- Are there several components with various clocks constrained to the problem clock region (i.e., IO clocks)? Can they be moved elsewhere?

- Is there a clock domain in the clock region that could easily be constrained elsewhere? Check for a slice-only clock domains with non-critical timing requirements.

- Are there large components (PPC, BRAM, DSP, etc.) with multiple clocks that could be constrained elsewhere?

Once you have decided on the constraint changes needed to resolve the clock region congestion, move the clock placement constraints found in the map log file (.map) to your user constraints file (.ucf) and edit them appropriately. For a complex clocking structure, It might take a few iterations to find a solution.
AR# 23480
Date Created 09/04/2007
Last Updated 12/03/2008
Status Active
Type General Article