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
Explorer
Explorer
366 Views
Registered: ‎09-25-2014

delay between two forwarded clocks

Jump to solution

Hi all,

I`m trying to output two clocks with a certain phase relationship (one for ADC clocking (20MHz) and other for some sensor clocking (40MHz)). My goal is to have less than 0.5ns diff delay variation due to PVT and run-to-run variability (preferably less than 0.5ns). Now I`m using two MMCM outputs, and phase of one of them is intended to be adjusted after some tests. Clock pathes are like this:

1)MMCM0_OUT1->BUFR->ODDR->PAD_ADC (BUFR is in "divide by 2 mode")

2)MMCM0_OUT6->BUFG->ODDR->PAD_SENS

The first thing I can`t understand is that path (1) delay about 0.6ns LESS than path (2) delay, still I can see on oscilloscope that there is about +0.5ns MORE delay on PAD_ADC. But may be I`m wrong in calculating path delay, because I just sum net route delays, which I take from implemented design and BUFR/BUFG delays from datasheet (it is about 1ns for dividing BUFR and 0.1ns for BUFG for Artix -1 grade)

1)MMCM0_OUT1->1.025ns->BUFR(1ns)->0.862ns->ODDR(??)->2ps->PAD_ADC(~70ps) = 2.959ns

2)MMCM0_OUT6->1.719ns->BUFG(0.1ns)->1.704ns->ODDR(??)->2ps->PAD_SENS(~70ps) = 3.595ns (0.636ns later than ADC)

Second thing is how to properly constrain it. Do I need to create_generated_clock from CLK_SENS and assume CLK_ADC as data line? Something like this:

create_generated_clock -name clk_sens_gen -divide_by 1 -source [get_pins ODDR_clk_sensor_inst/C] [get_ports CLK_SENS]
set_output_delay -clock [get_clocks clk_sens_gen] -max ??? [get_ports CLK_ADC]
set_output_delay -clock [get_clocks clk_sens_gen] -min ??? [get_ports CLK_ADC]

And what min and max values should be in such case?

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
140 Views
Registered: ‎01-23-2009

Re: delay between two forwarded clocks

Jump to solution

So, what constraints do I need to let tools know, that I need a certain phase relationship (t_delay +- some certain delta due to PVT) between CLK_ADC and CLK_SENS?

I am not sure you can really constrain one clock against another clock. While you could treat the 20MHz clock as "data" and the 40MHz as a forwarded clock, and then write constraints between them, I am not really sure what that would accomplish.

If your internal clock/clocks come from the MMCM outputs and they both use the same kind of buffer, and go to IOB flip-flops, then they will be "as skew constrained as they can be" - nothing here is placement/route dependent (since they all use fixed routing resources), and the PVT of the two clock paths will basically cancel eachother out.

Or, maybe, I just should fix routing to be sure that there wouldn`t be any run-to-run variability?

As I mentioned above, all of the routes involved in this path are "fixed"

  • Clock capable input to CLKIN of MMCM in same clock region
  • CLKOUTx to BUFG
    • In theory you can end up with different BUFGs from run to run, but.
      • The BUFG timing is basically identical between the different buffers
      • You could provide a LOC constraint to chose the BUFGs you want and not have it change
  • BUFG to "the entire fabric" including the ODDRs (this is the global clock network)

So you don't need anything else to "fix" the routes.

So the skew between them will be +/- approximately 600ps (or less) due to the PVT variations, +/-120ps due to the static phase offset of the MMCM plus any desired phase offset you specify through the CLKOUTx_PHASE parameter of the MMCM (and you can even use dynamic fine phase shifting).

Avrum

11 Replies
Scholar drjohnsmith
Scholar
350 Views
Registered: ‎07-09-2009

Re: delay between two forwarded clocks

Jump to solution
two things,
One a think. You need to constrain the two output clocks with reference to the same input clock to the MMCM ( I assume its just one MMCM )

One I'm certain about, ADC clock jitter, I don;t know how many bits your ADC is , but FPGAs internal clocks jitter way more than most ADC's need unless real low number of bits or low bandwidth signal,

And a totaly off the wall,
Have you thought about clocking both DDR registers off the same 40 MHz clock ?
Use the D input to the DDR to generate the two clocks ( 20 and 40 MHZ ) using a common 40 MHz clock.

Could you not then use the ODELAY to move the now perfectly synchronised clocks phase on the output pins.

BTW: Also assuming that both the 20 and 40 clock outputs are the same logic standard and in the same bank.


<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Explorer
Explorer
338 Views
Registered: ‎09-25-2014

Re: delay between two forwarded clocks

Jump to solution

Thank you for reply.
1)Yes, MMCM is only one. Do you mean I need something like System-Synchronous constraints? Timing constraints looks easy for me in theory, but It so hard every time it comes to do something on practice.
2)As I understand, ADC clock jitter matters for "continious" high frequency signal on input (higher slope around sampling edge->higher jitter influence). But I have analog multiplexed signal from image sensor, which is almost constant around sampling edge (and sensor mux should switch to next pixel right after sampling edge), so I think there is no need in high quality ADC clock source.
3)There is no ODELAY in Artix (my first idea was to use IDELAY, but than I read that it is a bad way because of very long routes when using to delay output). So I need two clocks with different phases. But still I can use BUFG instead of BUFR and divide frequency by driving D pins.
5)20 and 40 clock outputs are the same standart and on the same bank, but on different byte group (T0 and T3). Does it matters?

0 Kudos
Scholar drjohnsmith
Scholar
327 Views
Registered: ‎07-09-2009

Re: delay between two forwarded clocks

Jump to solution
not source sync.
Are you using the timing wizard ?

As for bufR and divide,

Confused, can you share your source code and constraints as an attachment,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Historian
Historian
293 Views
Registered: ‎01-23-2009

Re: delay between two forwarded clocks

Jump to solution

A couple of things.

Why are you using two different clock buffers - the BUFG for the sensor and BUFR for the ADC? These two clock buffers are very different - one is a global clock buffer located in the center of the die (the BUFG) and the other is a regional clock buffer (BUFR) located in the I/O column near the edge of the FPGA. These will have very different timing and PVT characteristics. Furthermore, you don't tell us what you are using for the feedback clock, of the MMCM and it may matter.

In general if you want two outputs to have "low skew" they should

  1. Come from IOB flip-flops, ODDR flops, or OSERDES
  2. Should be the same I/O standard
  3. Should be in the same bank if possible - closer is better
  4. Should use the same clock if possible
  5. If they can't use the same clock, then they should use two clocks that are topologically as similar as possibe

So you are using ODDRs (so that's #1). Also that they are the same I/O standard (#2) and the same bank (#3), so that's all good. That they are in different byte groups is not a big deal, but its just better for them to be physically closer together if possible and symmetrical around the middle of the bank if not possible - the worst skew will be between a pin in the center of the bank vs. a pin at either edge of the bank.

@drjohnsmith idea of using the same internal 40MHz clock to generate both of them is a good one:

  • For the 40MHz forwarded clock tie D1 to 1 and D2 to 0 of the ODDR
  • For the 20MHz clock have the D1=D2 at all times, and have them alternate between 0 and 1 on each clock

Doing this satisfied #4.

If you can't/don't want to do this, then you should change your clocking structure to use the same clock buffer for both. Since the clock is generated in an MMCM you should use either a BUFG (if the clock goes everywhere) or a BUFH if the clock is restricted to one region. But both clocks should (really must) use the same clock buffer. Why do you want to use a BUFR? Just to do the clock division? If so, why aren't you just asking for the 2nd output of the MMCM to be at 1/2 the frequency? If you can't have the MMCM do it, then I would highly recommend the solution above - there is no other "good" way of dividing a clock that is going to be forwarded out.

In terms of the actual skew, that's hard to say. If you do 1, 2, 3, and 4, then the skew is minimized - exactly how low it will be is hard to quantify; the tools say something like +/-600ps (which is pretty big), but if the pins are close together you will probably get better than that.

If you use two different clocks of the MMCM (#5) then you will add an additional tSTATPHAOFFSET (See the datasheet), which is +/-120ps in most architectures, plus a bit more for the PVT mismatch of the two global clock nets.

Using two different clock buffers (BUFG and BUFR), the variation will be significantly more than that, uncompensated and hard to estimate...

Avrum

Explorer
Explorer
189 Views
Registered: ‎09-25-2014

Re: delay between two forwarded clocks

Jump to solution

@drjohnsmith I can`t share a full version of project, so here is simplified version of top module in attachment.

ADC_sync.png

@avrumw Thanks for such detailed reply. 

CLKFBOUT and CLKFBIN are connected through BUFG. I don`t use Wizard.

Now I think I would change BUFR to BUFG and divide clock by driving D pin of ODDR, good idea, thanks.

I really need two things: certain (not zero) phase between 40MHz clock and 20MHz clock. So I can`t just use the same MMCM clock output (it could be possible . And a second thing: ability to invert 20MHz clock (there is another 20MHz, which is generated outside from FPGA (CLK_SENS_DIV) with unknown alignment to 40MHz clock, so CLK_SENS_DIV and CLK_ADC can be inverted relative to each other).

So, what constraints do I need to let tools know, that I need a certain phase relationship (t_delay +- some certain delta due to PVT) between CLK_ADC and CLK_SENS?

Or, maybe, I just should fix routing to be sure that there wouldn`t be any run-to-run variability?

0 Kudos
Scholar drjohnsmith
Scholar
181 Views
Registered: ‎07-09-2009

Re: delay between two forwarded clocks

Jump to solution

Can I guess your sampling a CCD output,

The ones i have seen have a clock output that is used by the FPGA to sample the data,

You have to use that as the CCD data output time is very variant on temprature / voltage.

As you have no ouput delay on the Artix, 

    Could I suggets you use the input delay on the data into the FPGA to scew the sample point 

   That way you could drive the 40 and 20 MHz clock out in phase, from the same clock source, 

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Explorer
Explorer
169 Views
Registered: ‎09-25-2014

Re: delay between two forwarded clocks

Jump to solution

@drjohnsmithYeah, some sort of CCD) I`ll try to ask manufacturer about a skew variability between sensor input clock CLK_SENS and sensor output clock  CLK_SENS_DIV, but from datasheet it looks like there is almost no skew.

About using delay line... It looks like you misunderstood what I mean by "sampling point". It is NOT the moment when FPGA samples data from 
ADC (I hope this will not be a problem, there is dedicated ADC data clock, not shown on my picture). It is a moment when ADC samples analog signal. So, if it is true about bad clock scew between CLK_SENS_DIV and CLK_SENS, than only option is to delay CLK_SENS_DIV clock by a 25ns (minus ADC sampling time about 1ns). Still, it is impossible with IDELAY, only dedicated MMCM or PLL can help (it is really bad for me, because MMCM consume pretty much power). So, it would be a really bad situation.

Only possibility to use IDELAY is to delay CLK_SENS, but it is strongly not recommended, because of long and unpredictable routes in chain BUFG->IDELAY->ODDR.

0 Kudos
Scholar drjohnsmith
Scholar
154 Views
Registered: ‎07-09-2009

Re: delay between two forwarded clocks

Jump to solution
yep your right,

double check with the manufacturer, they provide the clock out of the sencor for a very good reason,

Is power a problem to your design ?
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Scholar drjohnsmith
Scholar
151 Views
Registered: ‎07-09-2009

Re: delay between two forwarded clocks

Jump to solution
Do I guess your using something like this

https://www.cirrus.com/products/wm8214/

At high speed, the time to grab the data from the CCD is extremely small,
the manufacturer of the CCD expects you to use the sample output of the CCD to capture in the ADC,

then the FPGA grabs the data out of the ADC , effectively using a FIFO

Or this setup could be totaly different




<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Historian
Historian
141 Views
Registered: ‎01-23-2009

Re: delay between two forwarded clocks

Jump to solution

So, what constraints do I need to let tools know, that I need a certain phase relationship (t_delay +- some certain delta due to PVT) between CLK_ADC and CLK_SENS?

I am not sure you can really constrain one clock against another clock. While you could treat the 20MHz clock as "data" and the 40MHz as a forwarded clock, and then write constraints between them, I am not really sure what that would accomplish.

If your internal clock/clocks come from the MMCM outputs and they both use the same kind of buffer, and go to IOB flip-flops, then they will be "as skew constrained as they can be" - nothing here is placement/route dependent (since they all use fixed routing resources), and the PVT of the two clock paths will basically cancel eachother out.

Or, maybe, I just should fix routing to be sure that there wouldn`t be any run-to-run variability?

As I mentioned above, all of the routes involved in this path are "fixed"

  • Clock capable input to CLKIN of MMCM in same clock region
  • CLKOUTx to BUFG
    • In theory you can end up with different BUFGs from run to run, but.
      • The BUFG timing is basically identical between the different buffers
      • You could provide a LOC constraint to chose the BUFGs you want and not have it change
  • BUFG to "the entire fabric" including the ODDRs (this is the global clock network)

So you don't need anything else to "fix" the routes.

So the skew between them will be +/- approximately 600ps (or less) due to the PVT variations, +/-120ps due to the static phase offset of the MMCM plus any desired phase offset you specify through the CLKOUTx_PHASE parameter of the MMCM (and you can even use dynamic fine phase shifting).

Avrum

Explorer
Explorer
130 Views
Registered: ‎09-25-2014

Re: delay between two forwarded clocks

Jump to solution

@drjohnsmith We use AD9266 and we do not need CCD-specific features indeed)

@avrumw This sounds very good, thanks a lot for clarification. It makes me worry a lot much less)

0 Kudos