Divided clock relation

I have a clock, PLL_CLK from PLL, which goes to two different modules. Each module has its own dividers. The divided clock between the module1 and module2 should be treated as synchronous or asynchronous ? Example, M1_DIV4 and M2_DIV4 are sync or async to each other ?

The question goes back to your hardware design. Are the clock dividers synchronously reset to the same initial state? How much is the expectable delay skew? On the other hand, what's the reason for using different clock dividers with the same clock frequency?

A straightforward approach would be to consider the clocks as unrelated as long they are not sourced from the same clock divider.

For "normal" digital design:
1) If you don't care about the duty cycle of your divided clocks, you may want to use clock enable signal (generated by, say counter) to enable one cycle every 4(for DIV_4). This can replace the clock divider, and unify the design into single-clock domain. Of course, you may want to set multi_cycle_path in your constraints for synthesis.
2) If you do care about the duty cycle and the phase relationship between M1_DIV4 and M2_DIV4, FvM is correct. It is safer to treat them as async.

If you are designing some very high speed(over GHz) circuit for DLL or mixed-signal block, you may want to discard the concept of sync VS async, since it is stepping to analog world, and even digital 0/1 assumption does not apply on occasions. SPICE simulation is recommended.

FvM said:

The question goes back to your hardware design. Are the clock dividers synchronously reset to the same initial state? How much is the expectable delay skew? On the other hand, what's the reason for using different clock dividers with the same clock frequency?

A straightforward approach would be to consider the clocks as unrelated as long they are not sourced from the same clock divider.

Click to expand...

Thanks FvM. I have come across such a design in one of a recent projects. But the designer is not available to answer why two clock dividers are used for the same source clock. I believe by default it is safe to assume the divided clocks from different dividers as asynchronous to each other.

I think if you put module1 and module2 output clock async then there will not be any timing analysis .. even for a real path.

Check first if there is any communication happen from module 1 to module 2 or module 2 to module 1 .. if there are no signals communication then you can put as async. But if there are signals going/coming from module1 to module2 , then you need to consider the timing.

scenario 1 - if there is signal going from module1 to module 2

since source clock is same for both divider, tool will have timing information , tht how much time clock take to propagate from source clock to module1 or module2 , this information will be used.
clock delay will calculate from source clock , and in that case you cant define both clocks as async clock.

Rahul

If the divider is used is of not same type, and if the diverging clock source path is not balanced there is no guarantee the output clocks from module1 and module2 will be phase aligned. That is why it is better to treat the divided clocks from module1 and module2 as async and put up a synchronizer between them if there any datapath crossing exists.

well ... if you can take care all the datapath crossing , then yes , its better to declare as async clock , it will reduce complexity.

using asynchronous way could be easier, but how many scan chain do you have?, because if the clock aren't the same you need to have one scan clock by clock domain, manage the scan element by "scan clock" domain....

having one clock domain is more easy for scan chains.

Hi rca

I think scan may not be affected by clock domains. We can define a single scan_clock to chain flops in different domains. because in test_mode, when data is shifted, scan_clock can be always used, and during capture phase, the clocks can be switched to the respective functional clock domains. This is what we are doing now for our chips.

What is your main concern about scan clock VS clock domains?

Thanks
Leo

rca said:

using asynchronous way could be easier, but how many scan chain do you have?, because if the clock aren't the same you need to have one scan clock by clock domain, manage the scan element by "scan clock" domain....

having one clock domain is more easy for scan chains.

Click to expand...

Of course they are synchronous in frequency, but not necessarily in phase due to variations in active edge latency. Some counters are synchronous or async ripple cascade by design, which affects latency of edges.