1-bit synchronizer (CDC, metastability, 2 FF).

[Liffs]

Greetings all,

I have a basic question about a 1-bit digital signal (lets name it X) crossing asynchronous clock domains (lets says from clock domain A to clock domain B). The most used technique to perform such synchronization is using a 2-FF synchronizer, right? So I have two FFs clocked by clock B. The first one receives X and outputs X_1 (potentially metastable) and the second one receives X_1 and outputs X_2 (very likely to to be stable).
The question is: when X violates the first FF setup or hold timings, X_1 will become metastable for a while (lets say it is just for a little while). What does determine X_1 logic state when it goes back to be stable? Is it the value of X? Is it arbitrary?

Thanks!

 

[kaz1]

value of x input determines what x_1 will eventually settle at within one clock-B period

 

[dpaul]

The most used technique to perform such synchronization is using a 2-FF synchronizer, right?

Just a little correction, one should use a minimum of 2-FF synchronizer. 3 or 5 FF stages are very common in use!

 

[Liffs]

Just a little correction, one should use a minimum of 2-FF synchronizer. 3 or 5 FF stages are very common in use!

I thought 2-FF was still the most common. 3-FF to 5-FF are used for very high frequencies?

 

[dpaul]

It was just a re-phrase of your sentence! The word minimum is very important.

Actually it is the design engineer's decision!
I have seen Xilinx reset synchronizer block to have 5 stage flops.
Whereas in many of own designs, I have used 2 sync stages for signals which change max twice or thrice, and the design has been running successfully.

 

[kripsy]

The value after the first sync flop will settle to either 0 or 1 when you hit the setup/hold window. This is why the incoming value must be stable for multiple clock B cycles. The correct value will be captured on the next clock B cycle and your logic after the synchronizer will not know or care that there was the metastability.

 

[std_match]

The question is: when X violates the first FF setup or hold timings, X_1 will become metastable for a while (lets say it is just for a little while). What does determine X_1 logic state when it goes back to be stable? Is it the value of X? Is it arbitrary?

First, X_1 may become metastable if the setup/hold timing is violated. It can also settle nicely. This is about statistics and probability. You can't predict the settled X_1 value after metastability, it is a random function. If X_1 hasn't settled before the setup time of the next stage, you can't predict the X_2 output value, but the probability for metastability is reduced in each synchronizer stage. An unknown value is not the same as metastability. An unknown (stable) value is not a problem, metastability is a problem.

 

[Liffs]

First, X_1 may become metastable if the setup/hold timing is violated. It can also settle nicely. This is about statistics and probability. You can't predict the settled X_1 value after metastability, it is a random function. If X_1 hasn't settled before the setup time of the next stage, you can't predict the X_2 output value, but the probability for metastability is reduced in each synchronizer stage. An unknown value is not the same as metastability. An unknown (stable) value is not a problem, metastability is a problem.

"You can't predict the settled X_1 value after metastability, it is a random function." - okay, this is different from the previous replies I got so far. But that was my suspicious. Thanks!
Now, as stated by @kripsy, for this synchronizer to work the value of X must be stable for multiple clock B cycles, right? Otherwise, if it is stable for only one clock B cycle, the value of X_1 is random and so it will be the value of X_2. And the final goal of the circuit if to make X_2 match X.
So... if clock A and clock B have the same frequency, X must be stable for at least two clock A cycles?

 

[FvM]

I would answer the question slightly different. Consider a single transition, 0->1 or 1->0 in the signal send from first clock domain. It will cause a single transition after the synchronizer, in so far there's no randomness. The only point is that you can't exactly predict in which clock cycle the transition will be received. Therefore you can't use the synchronizer for multibit signals (except for gray coded signals that are guaranteed to have only one transition at a time), because you may receive inconsistent codes. E.g. "01" transiting to "10" may be received as "00" or "11" for one clock cycle.

 

[Liffs]

I would answer the question slightly different. Consider a single transition, 0->1 or 1->0 in the signal send from first clock domain. It will cause a single transition after the synchronizer, in so far there's no randomness. The only point is that you can't exactly predict in which clock cycle the transition will be received. Therefore you can't use the synchronizer for multibit signals (except for gray coded signals that are guaranteed to have only one transition at a time), because you may receive inconsistent codes. E.g. "01" transiting to "10" may be received as "00" or "11" for one clock cycle.

But there is randomness in the output of the first flop, do you agree? IF X_1 goes metastable, it will settle to either 1 or 0, unpredictable, before the next clock edge.

 

[std_match]

But there is randomness in the output of the first flop, do you agree? IF X_1 goes metastable, it will settle to either 1 or 0, unpredictable, before the next clock edge.

This is not a problem!
X = 000111
If the transition violates setup/hold X_1 will be 000X11
If X_1 settles before the next clock edge, X_2 will be 000111 or 000011 and both are OK!
The goal is to have a clean transition, and it doesn't matter if it happens in a specific clock cycle or in the next.

 

[Liffs]

This is not a problem!
X = 000111
If the transition violates setup/hold X_1 will be 000X11
If X_1 settles before the next clock edge, X_2 will be 000111 or 000011 and both are OK!
The goal is to have a clean transition, and it doesn't matter if it happens in a specific clock cycle or in the next.

But X can be 010101010...

--- Updated Nov 13, 2022 ---

 

[FvM]

010101010 is a marginal case. It can be only reproducd at the receiver side if Fclk2 > Fclk1.

 

[std_match]

But X can be 010101010...

--- Updated Nov 13, 2022 ---

View attachment 179679

The synchronizer transfers transitions between clock domains. The separation between transitions must be greater than the destination clock cycle. If you want to transfer single clock cycle pulses between domains, you need a different circuit. I normally do that by converting each pulse to a single transition (just a simple toggle FF), transfer to the other clock domain with a normal synchronizer, and then converting back to a pulse in the destination clock domain (an edge detector). However, the separation between pulses must be long enough.

 

[kaz1]

This is not a problem!
X = 000111
If the transition violates setup/hold X_1 will be 000X11
If X_1 settles before the next clock edge, X_2 will be 000111 or 000011 and both are OK!
The goal is to have a clean transition, and it doesn't matter if it happens in a specific clock cycle or in the next.

As far as I see it, the data value should be passed correctly so "both 000111 or 000011 being correct" is not right. Imagine both clocks are at same speed but unrelated. We could get errors regularly if we believe the literature that models metastability as a ball rolling on a hill that could settle either way. I know in practice the synchroniser works so my guess is that the "hill model" needs be revised.

 

[std_match]

As far as I see it, the data value should be passed correctly so "both 000111 or 000011 being correct" is not right. Imagine both clocks are at same speed but unrelated. We could get errors regularly if we believe the literature that models metastability as a ball rolling on a hill that could settle either way. I know in practice the synchroniser works so my guess is that the "hill model" needs be revised.

The synchronizer doesn't transfer "bits". The goal is to transfer a clean transition between clock domains. If the setup/hold times of the first stage is violated, you can't predict in which of the two possible clock edges in the destination domain the transition will happen.