Electrical – Temperature and Voltage variation affects on Metastability

The first FF is not always metastable. Assuming that input edges are uniformly distributed with respect to its clock, the first FF has a certain probability of going metastable that is related to the clock period and its setup/hold time requirements. If it does go metastable, it resolves itself within some amount of time — the probability of remaining metastable after time t is an exponentially decaying function of t.

The second FF has a much lower probability of going metastable, because it would have to get clocked at just the right instant when then first FF (if it was metastable) happened to be resolving itself. Otherwise, its output will be either definitely high or definitely low. The signal change might be delayed by an extended metastability of the first FF, but it is very unlikely to cause the second FF to go metastable and adversely affect the operation of the rest of the logic.

A third FF reduces the chances of metastability to infinitesimal levels.

The simple answer is that they don't on their own. The synchroniser is there not to ensure the data gets across, but the ensure you don't end up with metastable signals feeding lots of other signals and causing problems. The second FF as the diagram shows catches the metastable first FF output and prevents it propagating further through the design.

There are various sorts of signals, and how you include synchronisers depends on what signal you are talking about. But lets look at a couple of common types:

1. Trigger Signals - or any signal which is basically a pulse which must start something else running. These generally carry no data, and all you are interested in is that there is, say, a rising edge in order to start something going in another clock domain. To get these to cross over, you would need a synchroniser (essentially doing what is shown in your diagram), but you need a little bit more.

   The simplest option is to extend the pulse - essentially you make sure the input pulse is more than 1 clock periods of the destination clock (it should be longer than 1 cycle by at least the larger of the setup and hold times for the destination register). For example if you are going from a 20MHz clock to a 15MHz clock, you would make sure your pulse is two clock cycles at the input which would ensure that it is presented to the destination clock and not lost. This also answers your question in how the signal is guaranteed to go across. If the pulse is wider than one destination clock period it means that if it goes metastable on the first clock edge and ends up being seen as a 0, then on the second clock edge it will definitely catch the pulse.

   Because with this type of signal you are only interested that the pulse has gotten across, it doesn't matter if the output signal ends up with two clock cycles high some of the time and only one cycle the rest. If you need to ensure it is a single cycle pulse, you can instantiate a simple edge detector circuit.

2. Control Buses - or possibly types of data buses. These are arguably more difficult because if you have multi-bit data stream that needs to stay synchronised. In this case what you would do is implement something called "handshaking". You basically load your data on the source clock and hold it. Then you send a request signal (like in 1) across through a synchroniser. Once the request signal is across you know that the data bus will also be stabilised in the destination domain. You can then clock it into a register bank in the destination. The destination then sends an acknowledge pulse back again to inform the source that it can load the next word.

   You would use this sort of bus if you needed to send a control word to the destination clock for which you need to know that it has gotten there before you send another (e.g. if you are sending a command to do something).

3. Data buses - for data where you have a source that spits out data continuously or in bursts, you are arguably better off using a FIFO than synchronisers. The FIFO uses a dual-clock memory to hold the data, along with counters to keep track of how much data is in the FIFO. You write the data in to the FIFO when there is space, and then increment the write address. This address is then typically encoded into a "Gray Coding" scheme which ensures that each increment in address causes only one bit in the address bus to change (meaning you don't need to synchronise multiple bits). This address is then transferred to the destination domain (through one of your synchroniser chains), where it is compared with the read address. If there is data in the FIFO, it can then be read out of the memory using the destination clock port. The read address is similarly Gray coded and sent back to the source through another synchroniser so that the write port can calculate if there is any space in the FIFO.

4. Reset Signals - these typically use a modified version of the synchroniser in what is know as "Asynchronous Assert, Synchronous Deassert". In this modifed version, the data input to the first flip flop is tied to GND, and instead the incoming reset signal is connected to asynchronous preset signals of each flip-flop in the synchroniser. This results in an output signal which is entirely asynchronous when it goes high, but the synchroniser chain ensures that it goes low synchronously with the destination clock by clocking through zeros in the register chain.

   This type of synchroniser is terrible for data and control, but perfectly suited to reset signals. If all the destination logic feeds the output of this chain into the asynchronous reset inputs of any register in the domain, then there is little worry of metastability on assert (even though it is asynchronous) as all the registers are forced to a known state. Then when the reset signal is deasserted in the source domain, it synchronously deasserts in the destination domain meaning all registers come out of reset on the same clock cycle (rather than +/- 1 cycle if it was asynchronous deassert).

As you can see from the above, it is a lot more complex to do clock-domain crossing than to just stick a 2 flip-flop synchroniser on the signal. The exact method used depends on the application.