cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
8,278 Views
Registered: ‎04-27-2011

GT / BUFGCTRL Unroutable Placement

Jump to solution

I have a Virtex-6 VC6VLX240TFF1156-3 project with 8 GTX TX channels.  I'm using EDK 13.3.

 

Per the coregen example HDL, each GTX TX channel has an associated user clock (via a BUFG) which is utilized by both my code and the GTXE1.   One (and only one) of the derived user clocks is failing placement in the following way:

 

WARNING:Place:1146 - Unroutable Placement! A GT / BUFGCTRL clock component pair have been found that are not placed at a routable GT / BUFGCTRL site pair. The GT component <gtx_tx_rx_0/gtx_tx_rx_0/USER_LOGIC_I/gtx_tx_rx_top/[0].tx_primitive/gtxe1_i> is placed at site <GTXE1_X0Y12>. The corresponding BUFGCTRL component <gtx_tx_rx_0/gtx_tx_rx_0/USER_LOGIC_I/gtx_tx_rx_top/[0].txoutclk_bufg_i> is placed at site <BUFGCTRL_X0Y11>. The pair can use the fast path between the GT and the Clock buffer if the GT and BUFGCTRL are both placed in the same half of the device (TOP or BOTTOM). You may want to analyze why this problem exists and correct it. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <gtx_tx_rx_0/gtx_tx_rx_0/USER_LOGIC_I/gtx_tx_rx_top/[0].tx_primitive/gtxe1_i.TXOUTCLK> allowing your design to continue. This constraint disables all clock placer rules related to the specified COMP.PIN. This placement is UNROUTABLE in PAR and therefore, this error condition should be fixed in your design.

 

Note, that this was a fatal error until I added the CLOCK_DEDICATED_ROUTE qualifier to my UCF.

 

Three questions:

 

  1. Is this a duplicate of AR# 43894?  The bulletin indicates that this problem should not exist in 13.3, so I'm confused.
  2. Will this particular GTXE1 be reliable if I work around this problem with the CLOCK_DEDICATED_ROUTE modification in my UCF?
  3. If not, then what should I do?

Thanks,

 

Stacey

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
10,267 Views
Registered: ‎06-20-2008

The GT is placed in the top half of the device while the BUFG is being placed in the bottom half of the device.

 

This creates a situation where the dedicated clock resources cannot be used so setting CLOCK_DEDICATED_ROUTE=FALSE will allow this placement and will let the tools route the clock from the GTX to the BUFG using general resource routing.  This will lead to unpredictable routing delays, as generally stated in the error message, since the route will likely change each time you rerun the router.  It will also potentially introduce more distortion and or jitter to your clock since dedicated resources are not used.  The constraint was designed to allow you to place and route your design then examine the design in FPGA Editor to see what caused the unroutable placement. 

 

In this case your GTX is placed at site GTXE1_X0Y12 (Top Half) and the BUFG is placed at BUFG_X0Y11 (Bottom Half). 

Location constraining the BUFG to any of the top half sites should allow this design to route  ( "BUFGCTRL_X0Y16" through BUFGCTRL_X0Y31)

 

Now if you are using a BUFGMUX then you also have to make sure both sources of the BUFG are also in the top half of the device. The tools will create this unroutable situation when you use a BUFGMUX with one input in the bottom half of the device and the other input sourced from the top half of the device. If you are using a fixed pinout and cannot change it then you will need to decide which of the clocks will be least affected by using local interconnect. 

View solution in original post

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
10,268 Views
Registered: ‎06-20-2008

The GT is placed in the top half of the device while the BUFG is being placed in the bottom half of the device.

 

This creates a situation where the dedicated clock resources cannot be used so setting CLOCK_DEDICATED_ROUTE=FALSE will allow this placement and will let the tools route the clock from the GTX to the BUFG using general resource routing.  This will lead to unpredictable routing delays, as generally stated in the error message, since the route will likely change each time you rerun the router.  It will also potentially introduce more distortion and or jitter to your clock since dedicated resources are not used.  The constraint was designed to allow you to place and route your design then examine the design in FPGA Editor to see what caused the unroutable placement. 

 

In this case your GTX is placed at site GTXE1_X0Y12 (Top Half) and the BUFG is placed at BUFG_X0Y11 (Bottom Half). 

Location constraining the BUFG to any of the top half sites should allow this design to route  ( "BUFGCTRL_X0Y16" through BUFGCTRL_X0Y31)

 

Now if you are using a BUFGMUX then you also have to make sure both sources of the BUFG are also in the top half of the device. The tools will create this unroutable situation when you use a BUFGMUX with one input in the bottom half of the device and the other input sourced from the top half of the device. If you are using a fixed pinout and cannot change it then you will need to decide which of the clocks will be least affected by using local interconnect. 

View solution in original post

0 Kudos
Highlighted
Scholar
Scholar
8,244 Views
Registered: ‎07-01-2008

In addition to Lyman's comments I'll just add that the Answer Record doesn't apply to you unless you are using the core mentioned in a version prior to 13.3. That was a case of bad core generation (either connectivity or constraints) and not a tool issue.  If you are not using that core then your root cause is different but may be similar. You need to determine what  connectivity or constraint is causing the placer to be unable to satisfy the placement requirements of the GT/BUFGCTRL pair. To do that, override the clock dedicated route error with the constraint provided and then examine the resulting unroutable design in FPGA Editor to examine the connectivity of the two components.

0 Kudos
Highlighted
Adventurer
Adventurer
8,243 Views
Registered: ‎04-27-2011

Thanks, this workaround fixes the problem.

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
8,239 Views
Registered: ‎04-27-2011

I'm simply integrating coregen's example Verilog output into my 8 channel GTX project.  The GTXE1 primitive relies on a correctly located BUFG to provide a user clock with which I can then provide parallel data for serialization by the primitive.  The implication, as I now hopefully understand, is that GTXE1's are physically located on the die in such a way that the BUFG in the coregen sample code must also have location constraints, right?

 

If so, I would have expected the mapper to correctly deal with this situation.  Either that, or I would expect the example UCF file to constrain the 8 BUFGs to valid locations.  (This particular problem, simultaneous with this other ongoing problem, have now set my schedule back several days.)

 

Stacey

0 Kudos
Highlighted
Scholar
Scholar
8,237 Views
Registered: ‎07-01-2008

If you are able to add a constraint to get a legal placement, then that would be considered evidence of a Placer bug. It should have been able to find that solution automatically.

0 Kudos
Highlighted
Anonymous
Not applicable
6,926 Views

Hi,

 

I'm meeting the same problem.

I'm using kc705 and xps14.6.

I can't find the way to launch fpga editor in xps, can you show me how to launch it?

 

Thanks.

 

Jason

0 Kudos