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: 
Visitor antoniopug
Visitor
1,423 Views
Registered: ‎03-21-2018

Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

I am having an issue synthesizing a clock path for some DDR input lanes. I am using the XC7K70T Kintex-7 FPGA, and my interface consists of 4 LVDS data lanes (DDR) and 1 LVDS clock lane. In the clock path, I would like to use an IBUFDS followed by BUFIO/BUFR which can clock an ISERDESE2 on each data lane. The clock path code is as follows:

 

iclkdbuf : IBUFDS
	generic map (
		DIFF_TERM => term_en,
		IBUF_LOW_PWR => FALSE,
		IOSTANDARD => "DEFAULT"
	)
	port map(
		O => bit_clock_int_pre,
		I => dphy_clk(1),
		IB => dphy_clk(0)
	);

iclkbufio: BUFIO
	port map (
		O => bit_clock_int,
		I => bit_clock_int_pre
	);

clkdiv : BUFR
	generic map (
		BUFR_DIVIDE => "4",
		SIM_DEVICE => series
	)
	port map (
		O => byte_clock_int,
		CE => '1',
		CLR => reset,
		I => bit_clock_int_pre
	);

When I attempt to synthesize this design, I get a critical warning:

 

[Vivado 12-1411] Cannot set LOC property of ports, Could not legally place instance rx_phy/clkphy/iclkdbuf at L19 (IOB_X0Y108) since it belongs to a shape containing instance rx_phy/clkphy/iclkbufio. The shape requires relative placement between rx_phy/clkphy/iclkdbuf and rx_phy/clkphy/iclkbufio that can not be honoured because it would result in an invalid location for rx_phy/clkphy/iclkbufio. ["/home/antonio/fpga/GlueBoard/DAVID_CSI/vivado-2018-03-27_0958/DAVID_CSI/DAVID_CSI.srcs/constrs_1/imports/new/stream1.xdc":76]

 

As I understand it, this message means that the design can only associate either the BUFIO or the IBUFDS with the pins the clock arrives on, but not both.

 

Could you please confirm my understanding of this error and suggest ways to get around it?

 

Thank you.

1 Solution

Accepted Solutions
Historian
Historian
1,926 Views
Registered: ‎01-23-2009

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Nope. If the clock input is not on SRCC/MRCC pins you cannot use the BUFIO/BUFR; the only other way to access them is from the MMCM, and that doesn't make sense in this case.

 

So the only structurally legal clocking option you have is to come in from the pads, go to an MMCM, which will generate both the high and low speed clocks (the CLK and CLKDIV of the ISERDES), using either BUFGs for both of them or BUFHs for both of them.

 

However, the timing of this (or any other solution that doesn't have the clock on an SRCC/MRCC pin) will be "bad" - if this interface is running at any reasonable speed, nothing you will do will make this work with static timing.

 

Avrum

7 Replies
Historian
Historian
1,410 Views
Registered: ‎01-23-2009

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

The structure of what you are describing is legal as long as the IBUFDS is on a clock capable (MRCC or SRCC) pin.

 

As for the error message, it has to do with the LOC constraint. For this system, you only need PACKAGE_PIN constraint on the ports dphy_clk(0) and dphy_clk(1) - there should be no other location constraints; the BUFIO and BUFR will automatically be placed on the only BUFIO/BUFR pair that can be connected to the selected clock capable pin.

 

Avrum

Visitor antoniopug
Visitor
1,405 Views
Registered: ‎03-21-2018

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Ok that makes sense. The issue then is that those pins are not MRCC/SRCC.

 

I don't have the flexibility to re-assign pins since the pinout of our daughter card is fixed. Do you have any suggestions on alternative structures which can fit these constraints?

0 Kudos
Historian
Historian
1,927 Views
Registered: ‎01-23-2009

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Nope. If the clock input is not on SRCC/MRCC pins you cannot use the BUFIO/BUFR; the only other way to access them is from the MMCM, and that doesn't make sense in this case.

 

So the only structurally legal clocking option you have is to come in from the pads, go to an MMCM, which will generate both the high and low speed clocks (the CLK and CLKDIV of the ISERDES), using either BUFGs for both of them or BUFHs for both of them.

 

However, the timing of this (or any other solution that doesn't have the clock on an SRCC/MRCC pin) will be "bad" - if this interface is running at any reasonable speed, nothing you will do will make this work with static timing.

 

Avrum

Visitor antoniopug
Visitor
1,381 Views
Registered: ‎03-21-2018

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Ok. Thanks for your responses, this was very helpful.

0 Kudos
Visitor antoniopug
Visitor
1,365 Views
Registered: ‎03-21-2018

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Can you explain why timing would be "bad"? If it's bad what is the point of being able to route from general I/O pads to MMCM?

0 Kudos
Moderator
Moderator
1,359 Views
Registered: ‎04-18-2011

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

There is dedicated connection from the CCIO to the Clock Management tile in the clock region. 

The tools understand this dedicated path very well and therefore the clock and be deskewed by the MMCM. 

 

The problem with going from a non-CCIO to the MMCM is that the this route is not dedicated. 

It is general routing, so now in theory the clock to the MMCM is in competition with every other net for the routing resources. 

The MMCM won't be able to deskew the clock now. 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Historian
Historian
1,356 Views
Registered: ‎01-23-2009

Re: Clock Path Synthesis - IBUFDS and BUFIO

Jump to solution

Can you explain why timing would be "bad"? If it's bad what is the point of being able to route from general I/O pads to MMCM?

 

It depends on what you want to do with the clock.

 

If the clock in question is just a frequency reference, then it is OK. But if the phase is important, then the route from the non-CCIO to the MMCM is somewhat unconstrained, and hence the phase of the output clock (the output of the MMCM on the global clock) will not be tightly correlated with the phase of the input clock.

 

If the input clock is the reference for an interface (as it is in this case), then the mismatch between the phase of the input clock and the phase of the global clock will add uncertainty to the data capture of the input. In general the uncertainty here is large enough to kill the timing of any interface running at a "reasonable" speed.

 

So it is structurally allowed for cases where the phase doesn't matter....

 

Avrum