cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
caryan
Observer
Observer
10,030 Views
Registered: ‎04-17-2014

New Place error in Vivado 2015.3

Jump to solution

We have a design where we xor two clocks together - one on a BUFG and one on a BUFR - to try and measure their relative phase.  This worked fine in 2015.1 but now fails in 2015.3 with `[Place 30-174] Unroutable Placement!`. In particular:

 

* Artix 7 part

* one clock comes into clock region X1Y3 into an MMCM and then onto a BUFG

* another clock comes into clock region X1Y1 through a IBUFDS and BUFR

* Place now fails with 

[Place 30-174] Unroutable Placement! The following clock source components are placed too far from each other.  These clocks drive common load instances. This requires them to be placed in a relative way such that both clocks can drive the common load instances. Please refer to the clocking user guide for more details on which clock regions these clock sources can drive. 
	WFOutputA/clkout_buf_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y4
	 SYSCLK_MMCM_inst/inst/mmcm_adv_inst (MMCME2_ADV.CLKOUT0) is provisionally placed by clockplacer on MMCME2_ADV_X1Y3
	 WFOutputA/clk_phase/phase_sync[0]_i_1 (LUT2.I0) cannot be placed
	 WFOutputA/clk_phase/phase_sync[0]_i_1 (LUT2.I1) cannot be placed

	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_bufh_bufr_ramb
	Status: PASS 
	Rule Description: Reginal buffers in the same clock region must drive a total number of brams less
	than the capacity of the region
	 WFOutputA/clkout_buf_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y4

	Clock Rule: rule_iotile_bufr
	Status: PASS 
	Rule Description: An IO driving a BUFR must both be placed in the same clock region
	 WFOutputA/ibufds_clk_inst (IBUFDS.O) is locked to IOB_X1Y74
	 WFOutputA/clkout_buf_inst (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y4


	Clock Rule: rule_mmcm_bufg
	Status: PASS 
	Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device
	 SYSCLK_MMCM_inst/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y3
	 SYSCLK_MMCM_inst/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y27

	Clock Rule: rule_gclkio_mmcm_1load
	Status: PASS 
	Rule Description: An IOB driving a single MMCM must both be in the same clock region if CLOCK_DEDICATED_ROUTE=BACKBONE
	is NOT set
	 SYSCLK_MMCM_inst/inst/clkin1_ibufgds (IBUFDS.O) is locked to IOB_X1Y176
	 and SYSCLK_MMCM_inst/inst/mmcm_adv_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y3

 

The placer is putting everything where I expect but it almost seems that it is missing the BUFG and seeing the driver as the direct MMCM output

0 Kudos
1 Solution

Accepted Solutions
bwade
Scholar
Scholar
17,223 Views
Registered: ‎07-01-2008

You are seeing this regression due to a new 2015.3 logic_opt optimization that pushes non-sequential BUFG loads to the front side of the BUFG. This AR is not an exact match for your issue, but the same param work around should fix your problem by restoring the 2015.2 behavior.

 

http://www.xilinx.com/support/answers/66086.html

 

There have been multipe CRs related to this optimizaton and there are bugfixes coming in 2016.1 so that this optimization is done more approprately. 

 

Bret

View solution in original post

6 Replies
caryan
Observer
Observer
10,016 Views
Registered: ‎04-17-2014

A couple quick updates:

 

1. Vivado 2015.4 has the same issue.

2. Fixing the BUFG at a random BUFGCTRL in the X1Y3 clock region

set_property LOC BUFGCTRL_X0Y24 [get_cells sys_clk_mmcm_inst/inst/clkout2_buf]

 

fixes this issue.  However, it always seems something is wrong when I have to manually locate something.

0 Kudos
vemulad
Xilinx Employee
Xilinx Employee
9,512 Views
Registered: ‎09-20-2012

Hi @caryan

 

What is the site at which the BUFG instance is placed in 2015.1 passing design?

 

Is it possible for you to share post opt.dcp file for investigation?

 

Thanks,

Deepika. 

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
caryan
Observer
Observer
9,357 Views
Registered: ‎04-17-2014

@vemulad thanks for having a look.  I've put together a minimal example design showing succesful PAR in Vivado 2015.1 and failing in 2015.3 The 2015.3 project is created by opening the 2015.1 version, upgrading the IP and rerunning synthesis and implementation up to the place error above.

 

 

0 Kudos
bwade
Scholar
Scholar
17,224 Views
Registered: ‎07-01-2008

You are seeing this regression due to a new 2015.3 logic_opt optimization that pushes non-sequential BUFG loads to the front side of the BUFG. This AR is not an exact match for your issue, but the same param work around should fix your problem by restoring the 2015.2 behavior.

 

http://www.xilinx.com/support/answers/66086.html

 

There have been multipe CRs related to this optimizaton and there are bugfixes coming in 2016.1 so that this optimization is done more approprately. 

 

Bret

View solution in original post

vemulad
Xilinx Employee
Xilinx Employee
9,330 Views
Registered: ‎09-20-2012

Hi @caryan

 

Just to add to Bret's comments, 

 

I ran the test case which you have shared in 2016.1 internal build where it completed succesfully.

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
caryan
Observer
Observer
9,294 Views
Registered: ‎04-17-2014

Thanks for the updates folks.  Look forward to 2016.1

0 Kudos