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
7,917 Views
Registered: ‎07-28-2008

Source Synchronous IOCLK regeneration freq mismatch, safe?

Jump to solution

I am working on an IDDR2 design where external clock frequency is 176MHz.

 

IDDR2 DCM Deskew.png

By using clock wizard or instantiate DCM_SP, generated clock period has finite precision while 176MHz asks for infinite precision.

 

DCM_SP.CLOCKIN_PERIOD = 5.681; period precision loss = (1/176E6 - 5.681E-9), is 25KHz mismatch. External source synchronous data clock is 176MHz, while generated C0/C1 are 176.025MHz (CoreGen reported).

 

Theoretically, after 6945-clk cycles, generated clock overruns data clock by one-clock period, due to frequency mismatch. Does DCM_SP work in a free running mode out of CLKIN, or actually there is no concern for the mismatch, since generated clock (CLK0, CLKFX, CLK180) have stricly edge alignment with CLKIN in any frequency?

 

Is having the external data-clock being not-precisely regeneratable a bad decision? Or using BUFIO2 to perform simple clock inversion will create less frequency mismatch (BUFIO2.DIVIDE \= 2 ruled out this option).

 

Any comments are appreciated.

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
15,470 Views
Registered: ‎01-23-2009

Re: Source Synchronous IOCLK regeneration freq mismatch, safe?

Jump to solution

What you are looking at here is simple rounding of some numbers used for analysis. They do not reflect any inaccuracies in the clock.

 

If your DCM input is 176.00000000000000MHz, the output of the DCM will be 176.000000000000000MHz. The DCM is not regenerating the clock - it is merely modifying the one coming in using a 1:1 ratio.

 

However, when it comes to constraints and attributes, the tools use a finite precision - they are representing the clock as a 5.681ns period. This timing number is only used for analysis by the tool (and the CLOCKIN_PERIOD is really only used for simulation and limit checking anyway). This has no effect on the actual clock generated by the DCM.

 

In fact, the DCM is based on a Delay Locked Loop (DLL) - the whole point of this is that the regenerated and buffered clock at CLKFBIN is in phase and completely frequency locked with the clock at CLKIN; there will be a one for one edge tracking, and the phase error between them will be very small (in the neighbourhood of 100ps).

 

So, there is no problem here.

 

However, I am wondering why you are using CLKFX and CLKFX180 rather than the CLK0 and CLK180. If I understand you correctly you want C0 and C1 to be the same frequency as CLKIN - you don't need the CLKFX for this - you only need CLKFX if the clock you want for C0 and C1 are not the same as CLKIN, or twice the frequency of CLKIN (using CLK2X and CLK2X180). The jitter performance and phase matching of CLK0 are better than CLKFX...

 

Avrum

Tags (2)
2 Replies
Historian
Historian
15,471 Views
Registered: ‎01-23-2009

Re: Source Synchronous IOCLK regeneration freq mismatch, safe?

Jump to solution

What you are looking at here is simple rounding of some numbers used for analysis. They do not reflect any inaccuracies in the clock.

 

If your DCM input is 176.00000000000000MHz, the output of the DCM will be 176.000000000000000MHz. The DCM is not regenerating the clock - it is merely modifying the one coming in using a 1:1 ratio.

 

However, when it comes to constraints and attributes, the tools use a finite precision - they are representing the clock as a 5.681ns period. This timing number is only used for analysis by the tool (and the CLOCKIN_PERIOD is really only used for simulation and limit checking anyway). This has no effect on the actual clock generated by the DCM.

 

In fact, the DCM is based on a Delay Locked Loop (DLL) - the whole point of this is that the regenerated and buffered clock at CLKFBIN is in phase and completely frequency locked with the clock at CLKIN; there will be a one for one edge tracking, and the phase error between them will be very small (in the neighbourhood of 100ps).

 

So, there is no problem here.

 

However, I am wondering why you are using CLKFX and CLKFX180 rather than the CLK0 and CLK180. If I understand you correctly you want C0 and C1 to be the same frequency as CLKIN - you don't need the CLKFX for this - you only need CLKFX if the clock you want for C0 and C1 are not the same as CLKIN, or twice the frequency of CLKIN (using CLK2X and CLK2X180). The jitter performance and phase matching of CLK0 are better than CLKFX...

 

Avrum

Tags (2)
Explorer
Explorer
7,894 Views
Registered: ‎07-28-2008

Re: Source Synchronous IOCLK regeneration freq mismatch, safe?

Jump to solution

Thanks to avrum.

 

Knowing DCM_SP.CLOCKIN_PERIOD is for analysis only is very important for me.

 

CLKFX* are from ug382 examples, I will use CLK0 and CLK180 instead.

0 Kudos