clock domain crossing synchronizer

[promach]

Why 1.5x ratio limitation for Synchronizing Slow Signals Into Fast Clock Domain ?

 

[FvM]

Problem is that the prerequisitions of the > 1.5 criterion are not discussed. I doubt that it's generally applicable, e.g. for a continuous toggling signal.

To answer the question yourself, check how the signal of interest is reproduced when being sampled with a faster clock.

--- Updated Sep 5, 2021 ---

If we presume that the slow signal is potentially toggling at every active source clock edge, it would be sufficient that the destination clock is slightly faster with a margin defined by the maximal jitter sum.

 

[promach]

I do not quite understand what it means by “three receiving clock edge in which Litterick's paper does not really explain

 

[barry]

I'm not sure, but I don't think the 1.5x frequency is a guarantee of reliable data capture. If the slow-domain data violates set-up time of the fast clock flip-flop, you'll get a metastability. If you read the data on the second clock, you've got bad data. You still need an extra ff and clock to mitigate the metastability.

 

[ads-ee]

@barry, you are discussing frequency and the possibility you might need a 3 stage synchronizer.

The paper the OP has quoted is discussing the width of the slow clock data being transferred to the faster clock domain to reliably have at least 1 of the clock edges in the faster domain seeing a valid setup/hold of the signal in the slower clock domain.

The 1.5x cycle width is to guarantee that any signal from the slow clock domain is stable for a least 1.5 cycles of the faster clock domain (assuming the setup+hold isn't >=0.5 of the faster clock domain)

 

[barry]

@barry, you are discussing frequency and the possibility you might need a 3 stage synchronizer.

The paper the OP has quoted is discussing the width of the slow clock data being transferred to the faster clock domain to reliably have at least 1 of the clock edges in the faster domain seeing a valid setup/hold of the signal in the slower clock domain.

The 1.5x cycle width is to guarantee that any signal from the slow clock domain is stable for a least 1.5 cycles of the faster clock domain (assuming the setup+hold isn't >=0.5 of the faster clock domain)

the OPs original citation made no mention of data width.

”...not a problem as long as faster clock is >1.5x frequency...”

 

[promach]

Why exactly the assumption of setup+hold isn't >=0.5 of the faster clock domain is needed ?

 

[kaz1]

Why exactly the assumption of setup+hold isn't >=0.5 of the faster clock domain is needed ?

This has nothing to do with setup/hold as the clocks are not related so setup/hold will be violated and that is why we use two stage synchroniser.
The pulse width is the issue. if clocks are too close the fast clock may never see (sample) the pulse as it would hit the rise or fall window. So either make the pulse longer directly by logic or have the fast clock period shorter (by some arbitrary factor) .

 

[promach]

See https://electronics.stackexchange.com/a/585840/36150

 

[kaz1]

See https://electronics.stackexchange.com/a/585840/36150

Considering tSU/tH in this context doesn't make any sense to me.
The discussion is about sampling the output of a flip from clock1 domain into clock2 domain.
tSU & tH applies to D input not Q output. Hence it does not apply to Q output of clock1 but applies to D input of clock2 flip. This has to be protected by two stage synchroniser.

 

[ads-ee]

The pulse from the slower clock domain can easily violate either the setup or hold requirement of the first FF (of the 2 stage synchronizer) on the faster clock domain as the Tsu + Th = 0.5 *clk(period).

Is this Tsu + Th of 0.5 of the clock period reasonable, perhaps not, but I believe it is why the author of the paper suggested that the limit was slow_clk >= 1.5 * faster_clk to guarantee being able to capture a pulse in the faster clock domain as it is highly unlikely you would implementing a design where the Tsu + Th of a FF is half of your clock period.

No mater what is the Tsu and Th of the capturing FF, the slow clock must have a period that exceeds the period of the faster clock + (Tsu + Th) (of the capturing FF) + clock_cycle_jitter to ensure that at least one of the clock edges can reliably capture the pulse.

 

[gkram]

I do not quite understand what it means by “three receiving clock edge in which Litterick's paper does not really explain

View attachment 171792

The reference paper by Mark Litterick has a good description of the 3 clock edge (in fast clock domain) requirement. Remember that a synchronizer fights metastability (ie. the bad thing that happens to output of a register when setup and hold requirements are not met at the input to the register).
So, consider passing a digital pulse from a slow clock-domain to a fast clock-domain through the synchronizer. Since the clocks for the two domains are asynchronous, the rising edge of the pulse may cause the first register of the synchronizer to go metastable. Also, the falling edge of the digital pulse may cause the first register of the synchronizer to go metastable. So, a the fast clock has to sample the digital pulse at least three times to ensure that at least one sample has not caused the first register of the synchronizer to go metastable. Hence the 3 clock edge requirement stated by Litterick.