cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Contributor
Contributor
2,738 Views
Registered: ‎10-09-2017

[Place 30-510] Unroutable Placement

Jump to solution

Hi,

There are 4, 1 lane Aurora IPs on 214 MGT bank of XC7VX415TFFG1158-2 device. But only a pair of differential clocks are there for the same bank. I have configured all the 1 lane 4 IPs with the same clock pair and I am getting following error -

 

[Place 30-510] Unroutable Placement! A GTHE_COMMON / GTHE_CHANNEL clock component pair is not placed in a routable site pair. The GTHE_COMMON component can use the dedicated path between the GTHE_COMMON and the GTHE_CHANNEL if both are placed in the same clock region. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets aurora1/aurora_64b66b_1_block_i/gt_common_support/gt_qpllclk_quad1_in] >

aurora1/aurora_64b66b_1_block_i/gt_common_support/gthe2_common_i (GTHE2_COMMON.QPLLOUTCLK) is provisionally placed by clockplacer on GTHE2_COMMON_X0Y1
aurora1/aurora_64b66b_1_block_i/aurora_64b66b_1_i/inst/aurora_64b66b_1_wrapper_i/aurora_64b66b_1_multi_gt_i/aurora_64b66b_1_gt_inst/gthe2_i (GTHE2_CHANNEL.QPLLCLK) is locked to GTHE2_CHANNEL_X0Y1

The above error could possibly be related to other connected instances. Following is a list of
all the related clock rules and their respective instances.

Clock Rule: rule_gt_bufg
Status: PASS
Rule Description: A GT driving a BUFG must be placed on the same half side (top/bottom) of the device
aurora1/aurora_64b66b_1_block_i/aurora_64b66b_1_i/inst/aurora_64b66b_1_wrapper_i/aurora_64b66b_1_multi_gt_i/aurora_64b66b_1_gt_inst/gthe2_i (GTHE2_CHANNEL.RXOUTCLK) is locked to GTHE2_CHANNEL_X0Y1
aurora1/aurora_64b66b_1_block_i/aurora_64b66b_1_i/inst/aurora_64b66b_1_wrapper_i/rxrecclk_bufg_i (BUFGCTRL.I0) is provisionally placed by clockplacer on BUFGCTRL_X0Y2

Clock Rule: rule_bufds_gthcommon_intelligent_pin
Status: PASS
Rule Description: A BUFDS driving a GTHCommon must both be placed in the same or adjacent clock region
(top/bottom)
aurora1/aurora_64b66b_1_block_i/IBUFDS_GTXE2_CLK1 (IBUFDS_GTE2.O) is provisionally placed by clockplacer on IBUFDS_GTE2_X0Y3
and aurora1/aurora_64b66b_1_block_i/gt_common_support/gthe2_common_i (GTHE2_COMMON.GTREFCLK0) is provisionally placed by clockplacer on GTHE2_COMMON_X0Y1

 

Similar error for 3rd and 4th IP too.Can anyone help me to solve this?

 

Thank you

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
3,524 Views
Registered: ‎11-13-2017

It sounds like that 4 IPs have been instantiated, each utilizing a single transceiver (GTH_CHANNEL), but also each utilizing the shared QPLL (GTH_COMMON). 

Since there is only 1 QPLL for each transceiver quad, you will have to instantiate 3 of the Aurora IPs as being "Shared logic in Example design", so that the 3xIP instantiations do not contain the shared QPLL. The last Aurora IP instance should have the shared logic internal to the IP. Then you can route the necessary resets, clocks, etc. to the other 3 Aurora IPs. 

 

The reason Vivado is throwing you this error is (presumably) because there are 4 QPLLs to be placed in the same Quad, but it can only place 1 QPLL. Hence the other 3 are placed in nearby Quads, where we run into clock routing issues. 

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
2,633 Views
Registered: ‎02-14-2014

Hi @poornima_95,

 

As explained in the error message which you've faced, GTHE_CHANNEL and associated GTHE_COMMON has to be placed in same clock region to have dedicated connectivity between them. You can correct constraints accordingly and solve this issue.

If it doesn't help, share post-optimization checkpoint file (<top_level_name>_opt.dcp) to debug this further.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Contributor
Contributor
2,618 Views
Registered: ‎10-09-2017

Hi @ashishd

Thank you for the answer. But i could not solve this by changing the constraints.I have attached the post-optimization checkpoint file (aurora_top_module_opt.dcp) as you asked.

Regards,

Poornima.

0 Kudos
Highlighted
Adventurer
Adventurer
3,525 Views
Registered: ‎11-13-2017

It sounds like that 4 IPs have been instantiated, each utilizing a single transceiver (GTH_CHANNEL), but also each utilizing the shared QPLL (GTH_COMMON). 

Since there is only 1 QPLL for each transceiver quad, you will have to instantiate 3 of the Aurora IPs as being "Shared logic in Example design", so that the 3xIP instantiations do not contain the shared QPLL. The last Aurora IP instance should have the shared logic internal to the IP. Then you can route the necessary resets, clocks, etc. to the other 3 Aurora IPs. 

 

The reason Vivado is throwing you this error is (presumably) because there are 4 QPLLs to be placed in the same Quad, but it can only place 1 QPLL. Hence the other 3 are placed in nearby Quads, where we run into clock routing issues. 

View solution in original post