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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor caoyutinggg
Visitor
6,979 Views
Registered: ‎08-08-2017

Poor placement for routing between an IO pin and BUFG.

Jump to solution

Hi there

 

I'm trying to implement my SoC on KC705 board and this error keeps popping up. It seems that they are saying my clock is single ended and the pin provided by the board is differential, but I don't how that judgement is draw, my clock port is just one std_logic input.

Here is couple things I tried:

1. I tried to use the proposed command < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets reset_IBUF] >

the implementation went through, stuck at bitstream saying the single ended issue

2. I tried to connect it to different clock pins: system clock, user clock, non of them worked

3. I tried to use the IBUFGDS as suggested by some other threads:

begin
IBUFGDS_inst : IBUFGDS
generic map (
DIFF_TERM => FALSE, -- Differential Termination
IBUF_LOW_PWR => TRUE, -- Low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
IOSTANDARD => "DEFAULT")
port map (
O => Clock, -- Clock buffer output
I => clk, -- Diff_p clock buffer input (connect directly to top-level port)
IB => clk1 -- Diff_n clock buffer input (connect directly to top-level port)
);

still doesn't work :(

my xdc setup:

set_property PACKAGE_PIN AD11 [get_ports clk1]
set_property IOSTANDARD LVDS [get_ports clk1]
set_property PACKAGE_PIN AD12 [get_ports clk]
set_property IOSTANDARD LVDS [get_ports clk]
create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports clk]

 

This is the first time I try to implement something on a FPGA board so I'm very confused about a lot of things, any suggestion is welcomed. I will also attach my top vhdl file and the xdc constraint file.

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
10,595 Views
Registered: ‎01-23-2009

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

OK - so there are two things going on here.

 

First, lets deal with the differential/single ended thing. The KC705 has a 200MHz differential LVDS clock coming in on pins AD12/AD11 (for the P and N respectively). This is what it is; there really is an LVDS differential clock on these pins. So the instantiation of the IBUFDS and the PACKAGE_PIN and IOSTANDARD are correct.

 

This has nothing to do with the IO placement error. This is saying that there is a problem with a BUFG. BUT if you look at the name of the net and the name of the IOB, this is not the the clock input of the FPGA (AD12/AD11), this is associated with pin G12 (you need to actually go to the device view to translate the IOB_X0Y349 to be pin G12). Pin G12 is the GPIO_SW_C - the center push-button switch on the board.  The net is called reset_IBUF, so I presume it is being used as a reset.

 

From this message, there is clearly an BUFG connected to the output of the IBUF.

 

This got there either because

  - you have manually instantiated a BUFG on this net (maybe to provide fanout to the entire design) or

  - you are (presumably accidentally) using this signal as a clock to some flip-flop somewhere in your design

     - if you have an input port that drives the clock pin of any clocked cell, the tool will infer a BUFG on the net

 

The problem is that G13 is not a clock capable pin, and hence the tools are complaining about the route from G13 to the BUFG, which cannot be done with dedicated routing.

 

So, you need to figure out why the BUFG is there - did you put it there, or is it an accident. If it is an accident, then fix it - you need to figure out how/where you accidentally connected this net to a clocked cell's clock pin. If you put it there on purpose - why? If you really want to keep it, then you need to use the CLOCK_DEDICATED_ROUTE FALSE shown in the error message (but, I warn you, this is probably the wrong thing to do - there shouldn't be any reason to put this signal on a BUFG...)

 

Avrum

0 Kudos
6 Replies
Voyager
Voyager
6,976 Views
Registered: ‎06-24-2013

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

Hey @caoyutinggg

 

In your kintec7.xdc, you are setting the IO standard to LVDS ...

set_property PACKAGE_PIN AD12 [get_ports Clock]
set_property IOSTANDARD LVDS [get_ports Clock]

... which is a differential standard.

 

If your clock is on a single pin, change that to something like LVCMOS33 or LVCMOS25 (depending on your bank voltage) and the problem should go away.

 

Hope this helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Visitor caoyutinggg
Visitor
6,962 Views
Registered: ‎08-08-2017

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

Hi @hpoetzl

I want to thank you first for replying me.

 

I tried with your suggestion, changing the iostandard to LVCMOS15(I tried iostand lvcmos25 and 33, both indicate errors, and 15 seems to work.)

set_property BITSTREAM.CONFIG.BPI_SYNC_MODE Type2 [current_design]
set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN div-2 [current_design]
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.UNUSEDPIN Pullup [current_design]
set_property CONFIG_MODE BPI16 [current_design]
set_property CFGBVS VCCO [current_design]
set_property CONFIG_VOLTAGE 2.5 [current_design]
##CLOCKS
##SYSCLK
#set_property PACKAGE_PIN AD11 [get_ports clk1]
#set_property IOSTANDARD LVDS [get_ports clk1]
set_property PACKAGE_PIN AD12 [get_ports Clock]
set_property IOSTANDARD LVCMOS15 [get_ports Clock]
create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports Clock]

The original error is still there for some reason.

[Place 30-574] Poor placement for routing between an IO pin and BUFG. 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 reset_IBUF] >

	reset_IBUF_inst (IBUF.O) is locked to IOB_X0Y349
	 and reset_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31
0 Kudos
Visitor caoyutinggg
Visitor
6,961 Views
Registered: ‎08-08-2017

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution
Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device
INFO: [Timing 38-35] Done setting XDC timing constraints.
ERROR: [Place 30-574] Poor placement for routing between an IO pin and BUFG. 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 reset_IBUF] >

reset_IBUF_inst (IBUF.O) is locked to IOB_X0Y349
reset_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31
0 Kudos
Historian
Historian
10,596 Views
Registered: ‎01-23-2009

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

OK - so there are two things going on here.

 

First, lets deal with the differential/single ended thing. The KC705 has a 200MHz differential LVDS clock coming in on pins AD12/AD11 (for the P and N respectively). This is what it is; there really is an LVDS differential clock on these pins. So the instantiation of the IBUFDS and the PACKAGE_PIN and IOSTANDARD are correct.

 

This has nothing to do with the IO placement error. This is saying that there is a problem with a BUFG. BUT if you look at the name of the net and the name of the IOB, this is not the the clock input of the FPGA (AD12/AD11), this is associated with pin G12 (you need to actually go to the device view to translate the IOB_X0Y349 to be pin G12). Pin G12 is the GPIO_SW_C - the center push-button switch on the board.  The net is called reset_IBUF, so I presume it is being used as a reset.

 

From this message, there is clearly an BUFG connected to the output of the IBUF.

 

This got there either because

  - you have manually instantiated a BUFG on this net (maybe to provide fanout to the entire design) or

  - you are (presumably accidentally) using this signal as a clock to some flip-flop somewhere in your design

     - if you have an input port that drives the clock pin of any clocked cell, the tool will infer a BUFG on the net

 

The problem is that G13 is not a clock capable pin, and hence the tools are complaining about the route from G13 to the BUFG, which cannot be done with dedicated routing.

 

So, you need to figure out why the BUFG is there - did you put it there, or is it an accident. If it is an accident, then fix it - you need to figure out how/where you accidentally connected this net to a clocked cell's clock pin. If you put it there on purpose - why? If you really want to keep it, then you need to use the CLOCK_DEDICATED_ROUTE FALSE shown in the error message (but, I warn you, this is probably the wrong thing to do - there shouldn't be any reason to put this signal on a BUFG...)

 

Avrum

0 Kudos
Xilinx Employee
Xilinx Employee
6,943 Views
Registered: ‎08-25-2010

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

Hi @caoyutinggg

 

Please see the possible reason:

https://www.xilinx.com/support/answers/64452.html

 

Thanks

Simon

Thanks
Simon
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor caoyutinggg
Visitor
6,856 Views
Registered: ‎08-08-2017

Re: Poor placement for routing between an IO pin and BUFG.

Jump to solution

Thank you very much, I found out the issue is with the reset signal, it is not properly designed.

0 Kudos