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 jctaylor
Visitor
7,528 Views
Registered: ‎10-25-2013

Is it safe to set CLOCK_DEDICATED_ROUTE = FALSE in some cases?

Jump to solution

 

I am re-purposing a board that uses a Virtex-5 chip to run some experiments. Since the board is fixed, I cannot change the pin locations.

 

Several input pins ( data_in( 8 downto 0 ) ) that I am interested in are located on non-clock capable sites.

 

The data I expect to see on these pins is clock-like (i.e. a sequence of pulses with a mean frequency around 20 - 40 Mhz). I am interested in knowing the count of these pulses at precsribed times. My plan is to connect these pins to grey-counters that use this jittery clock-like signal as its the clock to count on. I will use a much more accurate clock for reading that count at prescribed times.  The grey code saves me from have a count error greater than 1.

 

The trouble I have is during place and route. The placer recognizes the signals as clocks (since they are used as the clock in a synchronous process) and gives me an error:

"ERROR:Place:645 -A clock IOB clock component is not placed at an optimal clock IOB site. .... you may use the CLOCK_DEDICATED_ROUTE constraint ..."

 

Okay, so I can turn this into a warning a complete my design.

 

If I set CLOCK_DEDICATED_ROUTE = FALSE am I throwing out all timing constraints in that clock region with it?  I don't care about a fixed lag of the signal (it is not synchronous with anything else in the design).

 

I am worried that it will not consider the timing of the logic used to realize the grey code incrementer. 

 

Am I correct in assuming that my only real timing issue is a lag (i.e phase delay) since the signal is taking a longer path before it gets onto proper clock routes? 

 

Are there other side effects of using the CLOCK_DEDICATED_ROUTE = FALSE for each of these signals?

 

The warnings on using this constraint are dire.

 

Is there a better way?

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
13,027 Views
Registered: ‎01-23-2009

Re: Is it safe to set CLOCK_DEDICATED_ROUTE = FALSE in some cases?

Jump to solution

I am assuming that you are routing the signals to clock buffers, and the clock buffers are then clocking the Gray code counter (and by the way, it is Gray code, not grey code, named after Frank Gray who first described them).

 

If so, then based on your description, the CLOCK_DEDICATED_ROUTE=FALSE should be OK - this just tells the tool "I know you don't have a dedicated route from the selected pin to the BUFG, and that is OK with me".

 

When you do this the clock will travel from the input pin (IBUF) to the global clock buffer (BUFG) using fabric routing. Because of this, the insertion latency is unknown and will vary from run to run. However, once it gets to the clock buffer, it is distributed as a clock, which means that the skew from the buffer to all clocked elements is balanced (as it should be for a clock). From what you describe, you shouldn't care about the insertion latency - just the mean frequency, which is preserved...

 

Furthermore, any constraints applied to the clock input will be properly propagated and even reported by the tool. If you apply a "create_clock" to the input pin the Gray code counters will all be properly constrained.

 

A couple of words of warnings/suggestions.

 

First, this is not a great way to do this, if there is any other way. For example, you could oversample the inputs with a higher frequency clock. Since your inputs are 20-40MHz, you could get away with a clock that is even as low as 100MHz; just double synchronize the inputs and count the rising edges on the 100MHz domain.

 

Second, if you do choose to do it the way you describe, be careful of how you transfer the Gray counts to the other domain:

  - the Gray counts must come directly from flip-flops - no combinatorial logic between the FFs on the individual clocks to the FFs on the stable clock

  - the Gray counts must have metastability resolution circuits; for Gray codes, this is 2 (or more) back to back flip-flops on each bit in the destination domain

     - all of the synchronizer FFs should have the ASYNC_REG property set on them

  - put a set_max_delay -datapath_only on the path between the FFs on the source domain and the first FFs on the destination domain

     - the value should be smaller than one period of your source clock (so 40MHz), but to be safe, I would probably use something even smaller than that

 

Avrum

0 Kudos
3 Replies
Moderator
Moderator
7,517 Views
Registered: ‎06-24-2015

Re: Is it safe to set CLOCK_DEDICATED_ROUTE = FALSE in some cases?

Jump to solution

Hi @jctaylor,

 

It will only affect the timing as it won't take dedicated routing.
Timing will be analyzed on the paths.

 

Thanks,
Nupur

Thanks,
Nupur
--------------------------------------------------------------------------------------------
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 (click on the 'thumbs-up' button).
0 Kudos
Historian
Historian
13,028 Views
Registered: ‎01-23-2009

Re: Is it safe to set CLOCK_DEDICATED_ROUTE = FALSE in some cases?

Jump to solution

I am assuming that you are routing the signals to clock buffers, and the clock buffers are then clocking the Gray code counter (and by the way, it is Gray code, not grey code, named after Frank Gray who first described them).

 

If so, then based on your description, the CLOCK_DEDICATED_ROUTE=FALSE should be OK - this just tells the tool "I know you don't have a dedicated route from the selected pin to the BUFG, and that is OK with me".

 

When you do this the clock will travel from the input pin (IBUF) to the global clock buffer (BUFG) using fabric routing. Because of this, the insertion latency is unknown and will vary from run to run. However, once it gets to the clock buffer, it is distributed as a clock, which means that the skew from the buffer to all clocked elements is balanced (as it should be for a clock). From what you describe, you shouldn't care about the insertion latency - just the mean frequency, which is preserved...

 

Furthermore, any constraints applied to the clock input will be properly propagated and even reported by the tool. If you apply a "create_clock" to the input pin the Gray code counters will all be properly constrained.

 

A couple of words of warnings/suggestions.

 

First, this is not a great way to do this, if there is any other way. For example, you could oversample the inputs with a higher frequency clock. Since your inputs are 20-40MHz, you could get away with a clock that is even as low as 100MHz; just double synchronize the inputs and count the rising edges on the 100MHz domain.

 

Second, if you do choose to do it the way you describe, be careful of how you transfer the Gray counts to the other domain:

  - the Gray counts must come directly from flip-flops - no combinatorial logic between the FFs on the individual clocks to the FFs on the stable clock

  - the Gray counts must have metastability resolution circuits; for Gray codes, this is 2 (or more) back to back flip-flops on each bit in the destination domain

     - all of the synchronizer FFs should have the ASYNC_REG property set on them

  - put a set_max_delay -datapath_only on the path between the FFs on the source domain and the first FFs on the destination domain

     - the value should be smaller than one period of your source clock (so 40MHz), but to be safe, I would probably use something even smaller than that

 

Avrum

0 Kudos
Instructor
Instructor
7,380 Views
Registered: ‎08-14-2007

Re: Is it safe to set CLOCK_DEDICATED_ROUTE = FALSE in some cases?

Jump to solution

The way you're doing this is exactly how a dual-clocked FIFO works.  I sometimes need to know the frequency of an input clock (although I'm usually also capturing data on that clock) and use a FIFO to generate a clock enable at the system clock frequency (greater than the input clock frequency) using !empty from the dual-clocked FIFO.  All that Gray code stuff is buried in the CoreGen or built-in FIFO, which is known to work and comes with the appropriate synchronization built in.  So in the end, you get your input frequency by counting the cycles during which "empty" is not asserted over some known period based on the system clock.

-- Gabor
0 Kudos