Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Community Forums
- :
- Forums
- :
- Vivado RTL Development
- :
- Timing Analysis
- :
- Re: Multiple Clock design 4 clock domains

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted

tkontogiorgis

Explorer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 06:05 AM

324 Views

Registered:
09-10-2019

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)

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

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

1 Solution

Accepted Solutions

Highlighted

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 10:41 AM

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

4 Replies

Highlighted
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.

klasha

Adventurer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 07:15 AM

310 Views

Registered:
05-23-2018

Highlighted

tkontogiorgis

Explorer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 07:45 AM

300 Views

Registered:
09-10-2019

Thank for the quick response @klasha ,really appreciated.

Did you mean this table?

So, as it seems my clock are synchronous right?

Thanks

Highlighted

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 10:41 AM

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

Highlighted

tkontogiorgis

Explorer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-27-2020 01:40 PM

261 Views

Registered:
09-10-2019