Clock Domains -> how defined?

Clock Domains -> how should be defined?

Hi All,

How clock domains should be defined? Let's say, should the source and divided by 2 clocks be defined as the same clock domain? What's about a clock divider by 3/5, etc?

What are the rules for clock domain definitions?

Thank you!

113 views and no replies. Tsk, tsk. That's what happens when you post a vague question. Anyway, read this: (from a Cadence paper)

"A clock domain is defined as that part of the design driven by either a single clock or clocks that have
constant phase relationships. A clock and its inverted clock or its derived divide-by-two clocks are
considered a clock domain (synchronous). Conversely, domains that have clocks with variable phase and
time relationships are considered different clock domain"

So for your examples, the divide by two clock is in the same domain, the 3/5 clock is not.

Re: Clock Domains -> how to destinguish?

From my understanding, clock domain is a clock tree with a guarantied skew between edges...

Will the source and its divided by 2 clock be always balanced (having a guarantee skew) during layout?

Will the source and its divided by 2 (3, 4, etc, ...) clocks always belong to the same clock domain?

Will the divided by 10 and divided by 32 clocks (divided from the same source clock) be considered as different clock domains?

Is there a way to balance (guarantee a max skew) the source and its divided by 3/5 clock?

Thank you!

- - - Updated - - -

Why the divided by 3/5 clock cannot be in the same domain with its source (in case it has just 3 pulses instead of 5 of the source clock and these pulses are aligned/balanced with the source clock pulses)?

- - - Updated - - -

You wrote: "clocks with variable phase and time relationships"

What's the difference between the clock phase and time relationships? How are they defined? Do you mean "clock periods relationship" under "time relationship"?

3/5 could be considered, but there will be edges that are not lined up, but also near in time to each other. Most developers would treat these as different because they would use async fifo's, synchronizers, etc... to ensure reliable signal crossings -- they would be treated as unrelated from a design standpoint. If the clock is low enough, timing could still be met, and you could consider them to be the same domain.

You could also track cycles and ensure the edges will align when data is transferred between the registers of the different clocks.


A common example for different clock domains would be serial communications. Both sides might have a 156.25MHz clock generated from a different source. The clocks can vary slightly over time, temperature, etc... So even though they are intended to be the same frequency, they are not exactly the same frequency. The result is clock edges near, but not aligned to each other. This means a register might update in one domain, logic might start to change, then the some mixture of correct and incorrect data will be registered in the other domain.