To ensure reliable operation in SoCs that have multiple asynchronous clock

domains, you have to synchronize clocks and data signals that cross
domains.
Clock-domain-crossing (CDC) issues come in many forms, and they can be quite challenging
to evaluate.Fortunately, the Synopsys DesignWare library offers many excellent CDC
solutions that are easy to apply so long as you understand when and where to apply them.
This paper explains the many types of synchronization issues that occur when clocks and
data signals cross from one clock domain to another.
• Basic synchronization — DW_sync
• Temporal event synchronization — DW_pulse_sync, DW_pulseack_sync
• Simple data transfer synchronization — DW_data_sync, DW_data_sync_na, DW_data_sync_1c
• Data flow synchronization — DW_fifo_s2_sf, DW_fifo_2c_df, DW_stream_sync
• Reset sequencing — DW_reset_sync
• Related clock system data synchronization — DW_data_qsync_hl, DW_data_qsync_lh
The most common way to tolerate metastability is to add one or more successive
synchronizing flip-flops to the synchronizer.
ClockDomainCrossingIssues
This section describes three main issues which can possibly occur whenever
there is a clock domain crossing. The solutions for those issues are also
described.
2.1 CLOCK DOMAINS
A clock domain is defined as that part of the design driven by either a single clock or clocks
that have
constant phase relationships.
A clock and its inverted clock or its derived divide-by-two clocks are considered a clock
domain (synchronous). Conversely, domains that have clocks with variable phase and time
relationships are considered different clock domains.
In Figure 1, the design has a single clock domain because the divCLK is the derived divide-by-
two clock of
the master clock CLK.

In Figure 2, multiple clocks come from different sources. The sections of logic elements driven
by these
clocks are called clock domains, and the signals that interface between these asynchronous
clock domains
are called the clock domain crossing (CDC) paths. The DA signal is considered an
asynchronous signal into
the clock domain—no constant phase and time relationship exists between CLK A and CLK B.
Basic synchronization issues
You need synchronization to achieve timing closure when signals from one clock
system are used as input in a second clock system that is asynchronous with respect
to the first. Without synchronization, you cannot achieve timing closure. Figure 1
shows the use of a single register to synchronize the asynchronous input to the
destination clock domain.

One issue with this approach is that metastability may occur when a flip-flop is
clocked while its data input
is in transition between logic 0 and logic 1. Metastability may also occur when a flip-
flop’s setup time or hold time is violated. The amount of time required to resolve a
metastable event to either a logic 1 or 0 depends on the degree of violation of setup
or hold time (Figure 2).

A.Metastability
Problem. If the transition on signal A happens very close to the active edge of clock C2,
it could lead to setup or hold violation at the destination flop "FB". As a result, the
output signal B may oscillate for an indefinite amount of time. Thus the output is
unstable and may or may not settle down to some stable value before the next clock edge
of C2 arrives. This phenomenon is known as metastability and the flop "FB" is said to
have entered a metastable state.
Metastability in turn can have the following consequences from a design perspective:
=If the unstable data is fed to several other places in the design, it may lead to a high
current flow and even chip burnout in the worst case.
=Different fan-out cones may read different values of the signal, and may cause the
design to enter into an unknown functional state, leading to functional issues in the
design.
=The destination domain output may settle down to the new value or may return to the old
value. However, the propagation delay could be high leading to timing issues.
For example, see Figure 2.
If the inputsignal A transitions very close to the posedge of clock C2, the output of the
destination flop can be metastable. As a result it can be unstable and may finally settle
to 1 or 0 as depicted by signals B1 and B2.

Solution. Metastability problems can be avoided by adding special structures

This structure is mainly used for single and multi-bit control signals and
single bit data signals in the design. Other types of synchronization schemes
are required for multi-bit data signals such as MUX recirculation, handshake,
and FIFO.
Solution.
In order to prevent data loss, the data should be held constant in the source
domain long enough to be properly captured in the destination domain.
In other words, after every transition on source data, at least one destination
clock edge should arrive where there is no setup or hold violation so that the
source data is captured properly in the destination domain.
There are several techniques to ensure this.
For example, a finite state machine (FSM) can be used to generate source data
at a rate, such that it is stable for at least 1 complete cycle of the
destination clock. This can be generally useful for synchronous clocks when
their frequencies are known. For asynchronous clock domain crossings,
techniques like handshake and FIFO are more suitable
2.2.2 Mean time between failures
The metastability occurrences can be predicted by using the mean time between failures
(MTBF) formula:

Where C1 and C2 are constants that depend on the technology used to build the flip-flop; tMET
is the
duration of the metastable output; and fclk and fdata are the frequencies of the synchronous
clock and
the asynchronous input, respectively.
3 STRUCTURAL DESIGN FOR SYNCHRONIZATION (sCDC)
3.1 SYNCHRONIZATION (CONTROL PATHS)
Designers can use special metastable hardened flops for increasing the MTBF. For example, in
Figure 4, a
synchronizer flop is used following the signal DB. So, instead of the metastable signal DB being
used in
the function downstream as in Figure 3, the stable signal DB2 is used in the logic downstream.

=========================================================
====================
For basic synchronization, you can use DesignWare’s DW_sync component, which has
these parameters:
• width
• f_sync_type: Number of stages
• tst_mode: 0 => No hold, 1=> latch, 2 => negedge FF
• verif_en (discussed later; does not affect synthesis)
When you specify the number of stages with the f_sync_type parameter, you get one
of the configurations shown in Figure 6.
A synchronizer fails when a metastable event lasts long enough to affect the next stage of
logic. The mean time between failures (MTBF) is commonly calculated as

Where:
Fclk = is the sampling clock frequency
Fdata = is the frequency of data changes
tres = is the time allowed for metastability resolution
T0 and T1 are constants related to the specific flip-flop (more on these later)
Often you cannot control the time budget to the next stage because synthesis usually tries to
downsize
gates to save area, as long as timing is met. To maintain a consistent resolution time, you can
use a
sequence of two flip-flops. This traditional solution does increase latency, however.
With the two-flip-flop solution, tres is based on the clock period reduced by the clock-to-Q
delay of FF1 and the setup requirement of FF2: