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: 
Contributor
Contributor
1,205 Views
Registered: ‎09-22-2017

Create clock signal from non-cc ping

Hi everyone,

 

I has a little problem with my design.

I receive a clock signal for a serial interface. This signal is defined on a non-CC pin (i have no choice to move it, pinout is already defined by my customer).

 

So in my design, this input signal is connected through an bufg then an ibufg. Then i use the output of this ibufg in my design.

Moreover i define the input as a clock signal in my constraint file.

( ls_clk -> BUFG -> IBUFG -> ls_clk_int)

 

Perhaps i make mistakes (of course else my design will work). When i run the implementation step, i have an error because my signal is not a non-CC pin. Vivado says that i must declare CLOCK_DEDICATED_ROUTE to FALSE,

 

Is my method is wrong ? (partially or totally) How can i correct my design ?

 

Thank you

 

0 Kudos
5 Replies
Highlighted
Historian
Historian
1,192 Views
Registered: ‎01-23-2009

Re: Create clock signal from non-cc ping

So, first I assume you made a mistake in your e-mail and the path is

 

ls_clk -> IBUF -> BUFG -> ls_clk_int

 

(the opposite order is illegal) and I would use an IBUF, not an IBUFG - they are the same thing, but you will get extra warnings trying to use an IBUFG, since an IBUFG is specifically telling the tool "I want an IBUF that I am planning to LOC to a clock capable pin" - since you are not using a clock capable pin, you should use an IBUF.

 

The whole point of a clock capable pin is that, in addition to regular "fabric" routing, it has extra dedicated routing to clock resources - notably the inputs of BUFG, BUFIO, BUFR, BUFH clock buffers as well as the CLKIN and CLKFBIN of MMCMs and PLLs. These dedicated routes provide for consistent timing and low clock insertion delays.

 

If you try and drive one of these resources from a non clock-capable pin, then it can still make the connection, but the connection goes through fabric routing. As a result it is slower and subject to variation from place and route run to run. Since this is a significantly lower performance mechanism, the tools want you to be sure that you know you are doing this, and therefore asks you to set the CLOCK_DEDICATED_ROUTE = FALSE on the net between the IBUF and BUFG. This is the mechanism used to tell the tools "I know I am using a sub-optimal solution, but it is really what I need".

 

This has nothing to do with static timing analysis - so far this has all been about device structure and place and route. The definition of a clock (create_clock) is for static timing analysis. It is totally independent of the above

  - it is perfectly legal (according to the rules of STA) to put a create_clock on a non clock capable pin. Static timing analysis will time it correctly (including showing the increased and variable delay of the clock insertion)

  - the use of a create_clock has no effect on the placer/router (at least not on the net from the IBUF to the BUFG) - specifically it does not (and is not supposed to) replace the need for the CLOCK_DEDICATED_ROUTE property.

 

Finally you don't tell us much about  this "serial interface" - specifically, you haven't told us how fast it runs. If it runs "fast", then it is going to be very difficult to get it to meet timing with the non-clock capable pin. If it runs "slow", then it can probably be made to work... However, if it runs "pretty slow" (like under 20MHz kind of slow), then it is probably easiest to not use the ls_clk as a "clock", but instead oversample it on some faster internal clock, and use the transitions on the oversampled signal to select which edge of the internal clock to use for sampling the other input signals or generating output signals. This avoids all the definition of this signal as a "clock", alleviates the need for the BUFG, removes the CLOCK_DEDICATED_ROUTE constraint, and is timed "normally" by the static timing engine.

 

Avrum

Tags (1)
Contributor
Contributor
1,175 Views
Registered: ‎09-22-2017

Re: Create clock signal from non-cc ping

Thanks for your answer.

 

Effectively, i didn't give any information about the serial clock frequency. Sorry.

So, entire design, is clocked by a 80MHz signal from a MMCM.

Serial interface frequency is 1.25MHz.

 

I'm not a work at this time, i can give you more information tomorrow (european timezone).

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

Re: Create clock signal from non-cc ping

At this frequency (1.25MHz), assuming the timing of the serial interface is "reasonable" (i.e. out of the 80ns period, the data is guaranteed to be valid for a reasonable percentage of that), this can easily be managed using oversampling (as I suggested above).

 

Avrum

0 Kudos
Contributor
Contributor
1,151 Views
Registered: ‎09-22-2017

Re: Create clock signal from non-cc ping

I 've checked this morning, and in fact my input signal is used as a clock signal for some flip-flops.

Those process use the input signal to sample data. Then, of course, data are resynchronized on main clock domain (according to a data valid signal).

That's why i thought that i need to route this signal to a decidated clock route. And  i thought that connected it to ibuf/bufg and with a constant will work. But it is not.

 

Maybe it is possible to lock the position of bufg as close as possible to the pad of my signal to reduce timing skew between ibuf and bufg ?

 

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

Re: Create clock signal from non-cc ping

Maybe it is possible to lock the position of bufg as close as possible to the pad of my signal to reduce timing skew between ibuf and bufg ?

 

All BUFGs are in the center of the die, and hence are essentially equidistant from a given input - so this won't make any difference.

 

At the frequency you are working at (again, assuming the interface has reasonable clock/data skew), you can get this interface to work without a clock capable input in either of two ways:

 

1) simply use the BUFG and set CLOCK_DEDICATED_ROUTE=FALSE

 

If you specify complete and accurate timing constraints for this interface and the timing analysis passes, then the interface will work. You will need to architect the clocking structure (which is probably as simple as determining if you will capture data on the rising or falling edge of the clock), but at this speed the interface should be relatively easy to get to meet timing

 

2) Do not use the input "clock" as a clock, but as a data signal that is oversampled on your main clock (as I described above)

 

Avrum

0 Kudos