How do you choose the appropriate synchronizer design for different types of CDC signals?

Not only does it not resolve CDC issues, but this is in fact an inappropriate design practice to synchronize any signal using a single FF design. This leads to issues due to low MTBF calculated from this type of design, and will always lead to intermittent failures that can definitely impact safety depending on the application the statement that the latency is of one clock cycle is not quite clear nor correct. In the end, the handshake of the synchronized control signals and relationship to the crossing data signals is what drives the performance and throughput of the system. And there are many schemes (gray-coding, wr/rd pointer synchronization) that change how much latency you want to allow for on that asynchronous data path

Single flop synchronizers is a good start in understanding CDC issues, but it does not resolve any CDC issue. It can help you understand the further advancements but it is not a solution.

single flip-flop can't solve CDC problem unless there is guarantee that signal won't change the state when clock is changing its state.

You can do it with a single flip-flop, BUT you have to guarantee the sampling clock is off when the data is changing. And the signal must be stable when enabling the sampling flop. I personally wouldn’t recommend doing it.

This is a god way to see CDC problems, not solve them. Unless you absolutely know the clock relationships, in which case it's not really CDC, you will encounter metastability at some point in this configuration.

These are majorly used in industry. The first flop in the 2 flop synchronizer is used for absorbing the metastability and the second flop us used to provided the sample stable output of the sampled signal. But it should be noted that they are not used for multi-bit signals. Also the if the frequency of operation is very high, you may want to increase the number of flops to 3 depending on the MTBF.

As has been pointed out, do not try to synchronize more than one bit of a bus this way. If you have multiple bits, use a FIFO or a ready/ ack strategy with a separate synchronized bit.

important note is that latency can be 2 or 3 cycles depending on the meta-stability of the first FF. if the FF sampled in the meta stable region the data output is unknow and there for could propagate in this cycle or the next. this could happen differently for samples in the same conditions. do not count on propagation time to be constant.

These are generically used for data synchronization between the clock domains. But these is again a catch here, how will you efficiently generate empty and full flag to avoid underflow and overflow. The solution to that is the use of Gray code, to pass the pointers across the clock domain. I know this is not the enough information. But try to imagine how will it solve the problem.

For any FIFO, a write pointer and read pointer has to be maintained for full and empty flag generation. The common practice is to use 1 extra bit to detect full and empty conditions correctly. However, it becomes challenging for asynchronous FIFO as the write pointer and read pointer gets updated in different clock domains. We need to be able to transfer the write pointer information to read domain and read pointer information to write domain. Gray code is useful for that transfer as it ensures that we are not off by more than one bit. However - this is just skimming the surface. It can get more complicated if one or both the clock domains are not on all the time.

These kind of synchronizers are used to pass control signals across the clock domain. There is a lot of latency involved with this kind of synchronization, but if your design permits that this should not be an issue as it is one of the most effective synchronization, with less gate count as compared to other methods of synchronization out there.

These synchronizers are used especially when the timing relationship between source and destination domains is unknown or variable.

This is not a kind of synchronizer, glitch filterers are just used to filter the glitches present on the signal that may be on external signal or due to some combo logic in your design. And not a solution for any kind of synchronization.

this is a combination of synchronizer of a signal and glitch filter, it can be separated into 2 functions or implemented as one.

Your sampling clock needs to be faster or same speed as the driving clock to guarantee capture, or you risk missing a pulse. You basically have to guarantee the driving signal is stable long enough to be sampled.

MUX Based Synchronizers: MUX-based synchronizers in CDC are typically used for transferring control signals or status flags from one clock domain to another. These are especially useful in scenarios where the data transfer involves single-bit control signals rather than multi-bit data.

Pulse synchronization: This is kind of synchronizer is used to pass signals that are intended to be active for small duration/one clock cycle. You cannot you any of the above synchronizer as due to the high frequency the destination domain can completely miss the signal. Hence there is a different circuitry that is specifically used to synchronize pulse.

The idea of pulse synchronization is to first latch the signal occurring for only one cycle in the high frequency domain. Once the receiving domain sees the signal- it can send an acknowledgement to clear the latched signal. Because of this constraint- a second pulse occurring within the time when latched signal was not reset would be missed.

I would simplify this a bit. The heart of a pulse synchronizer is a toggle synchronizer. You use the pulse or a change on the pulse signal to toggle a got, then synchronize the toggle to the other domain and detect a change in either direction to signal a pulse there. These are extremely reliable and pretty simple to understand.