cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
324 Views
Registered: ‎09-10-2019

Multiple Clock design 4 clock domains

Jump to solution

Hello,

We have a design with 4 clocks. 3 of the 4 clocks are synchronous (multiples x1,x2,x4). So in these 3 clocks we do put synchronizer. In the 4th clock ( x1.25 of base clk ) we do synchonization techniques. But my question is:

Suppose we have frequencies (40MHz,80,160MHz) for the 3 synchronized clocks. Thus , the clock period in ns is 25 , 12.5 , 6.25 which are rational values. So everything will work perfect (input clock is 100MHz here)

RationalValues.PNG

If we changes the values to the synchonous clocks (and also changin the input clock in 57.6 here) then we get the following:

ChangesClock.PNG

Actual values see to be the same as the Requested one but the clock period in ns consists of irrational numbers : 21.70138888888888888888888888889 , 10.85069444444444444444444444444 etc.

Will it be the "synchronous " clocks synchronous as Frequency indicates or will they  differ because the periods are not exactly the same?  Do i have to apply synchonization techniques in all the clock domains in the second case or Vivado implements the clocks with complete accuracy as in the first case?

Thank,

Theo

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
277 Views
Registered: ‎01-23-2009

@klasha answered your original question - the outputs of the MMCM are harmonically fundamentally harmonically related - they are all divisions of some common VCO clock. The fact that the periods and/or frequencies cannot be represented with a fixed number of digits is nothing more than a representation problem. In some earlier versions of the tools, they could be confused by inexact representations of harmonics (i.e. that 3.33333... was in fact really 1/3 of 10), but I haven't seen a problem in a while now - the tools have some kind of rounding algorithm that seems to work.

However, I also want to point out that even though two frequencies aren't exact multiples of each other doesn't necessarily imply that you need to treat them as asynchronous. Lets take your 40MHz and 50MHz clocks; the ratio between them is 1.25; they have periods of 25ns and 20ns respectively. It is, in fact, perfectly fine to cross between these two domains synchronously - the requirement on paths between them are 5ns, which is more than enough to do a synchronous clock crossing. You need to pay attention to the functionality to ensure that (for example) a pulse on the 40MHz domain is not interpreted as a two pulses on the 50MHz domain, but this can be done functionally - it doesn't need to be done by a clock domain crossing circuit.

Of course, this all assumes that all the outputs of the MMCM go through similar clock networks (i.e. they all use BUFGs) and, in the case of UltraScale/UltraScale+/Versal, all the clock nets are in the same CLOCK_DELAY_GROUP.

Avrum

View solution in original post

4 Replies
Highlighted
Adventurer
Adventurer
310 Views
Registered: ‎05-23-2018

The MMCMs create multiple Clocks by dividing down a fast running VCO with synchronized counters. For CLK0, the Counter can be fractional. Check the MMCM Settings tab to see the exact dividers. If all are integer, then you can assume that your synchronous clocks are proper synchronous relative to each other. What you are seeing is just display accuracy.

Highlighted
Explorer
Explorer
300 Views
Registered: ‎09-10-2019

Thank for the quick response @klasha ,really appreciated.

Did you mean this table? 

MMCM.PNG

So, as it seems my clock are synchronous right?

Thanks

0 Kudos
Highlighted
Guide
Guide
278 Views
Registered: ‎01-23-2009

@klasha answered your original question - the outputs of the MMCM are harmonically fundamentally harmonically related - they are all divisions of some common VCO clock. The fact that the periods and/or frequencies cannot be represented with a fixed number of digits is nothing more than a representation problem. In some earlier versions of the tools, they could be confused by inexact representations of harmonics (i.e. that 3.33333... was in fact really 1/3 of 10), but I haven't seen a problem in a while now - the tools have some kind of rounding algorithm that seems to work.

However, I also want to point out that even though two frequencies aren't exact multiples of each other doesn't necessarily imply that you need to treat them as asynchronous. Lets take your 40MHz and 50MHz clocks; the ratio between them is 1.25; they have periods of 25ns and 20ns respectively. It is, in fact, perfectly fine to cross between these two domains synchronously - the requirement on paths between them are 5ns, which is more than enough to do a synchronous clock crossing. You need to pay attention to the functionality to ensure that (for example) a pulse on the 40MHz domain is not interpreted as a two pulses on the 50MHz domain, but this can be done functionally - it doesn't need to be done by a clock domain crossing circuit.

Of course, this all assumes that all the outputs of the MMCM go through similar clock networks (i.e. they all use BUFGs) and, in the case of UltraScale/UltraScale+/Versal, all the clock nets are in the same CLOCK_DELAY_GROUP.

Avrum

View solution in original post

Highlighted
Explorer
Explorer
261 Views
Registered: ‎09-10-2019

Thanks you very much both @avrumw  and @klasha 

Sincerely,

Theo

0 Kudos