section describes a methodology which will ensure that the circuit has
been designed properly to handle the clock domain crossing issues
described in Sections 2 and 3.
The validation activity can be
divided into two categories, namely structural and functional.
Structural validation ensures that appropriate synchronization logic has
been added wherever it is required and functional validation ensures
that the logic which has been added is actually performing the intended
A number of CDC problems can be detected just by
performing structural validation. These checks are simpler and much
faster than the functional validation. Moreover, if there are structural
issues, most of the functional validation would have no relevance
anyway. Hence, verification should begin with the structural checks and
the problems detected there should be corrected before moving on to
Rule-based checking is a very efficient way to perform structural validation.
verification techniques can be used to perform functional validation.
Assertions can be inferred automatically in the design using some EDA
tools, or they can be inserted in the RTL using any of the standard
assertion languages like OVL, PSL and SVA. These languages are supported
by many EDA vendors.
These assertions can either be simulated
in the functional simulation environment or can be verified using formal
verification techniques. Both these techniques have their own
advantages and disadvantages.
The simulation results are
dependent on the quality of test vectors used. A problem may go
undetected if the vectors applied cannot stimulate it, and it is very
difficult to determine the right set of test vectors which will give
As compared to simulation, formal techniques give a
much better coverage and there is no need to provide any test vectors.
However, formal techniques have some performance issues because of state
space explosion which is a well known problem in formal analysis .
So, these checks are not suitable for full chip analysis but they work
reasonably well at the block level.
A step-by-step approach for verifying clock domain crossings is described here.
Check for the presence of valid synchronizers in:
- All asynchronous clock domain crossings, and,
cases of synchronous clock domain crossings where there can be
metastability as described in the section on rational multiple clocks.
multi-flop synchronizer is sufficient to ensure that there will be no
metastability. However, there can still be a problem of data
incoherency. So, it is advisable to check at this stage only, that
multi-flop synchronizers are used only for scalar signals. They can also
be used for control busses. They should not be used for data busses
A rule-based checker can be used to automatically detect
all clock domain crossings and to check for the presence of valid
synchronizers at all places where they are required.
If there are missing synchronizers, the designer should modify the design to add appropriate synchronization logic.
for the presence of separately synchronized signals which are
converging. These are probable candidates for data incoherency. These
candidates can be identified by doing structural analysis of the design.
candidate signals for data incoherency should be verified to be
Gray-encoded. This validation can be done through assertions. The
assertion itself could even be generated by a structural checking tool –
whenever it sees signals which are candidates for data incoherency.
15, shows a control bus clock domain crossing, which is synchronized
using a multi-flop synchronizer but is not Gray-encoded. A waveform
trace is generated for the assertion failure.
Figure 15. Gray-encoding failure using formal verification
case the converging signals cannot be Gray-encoded, change the
synchronization scheme to one which uses a common control signal, for
example, MUX recirculation, FIFO or handshake. These schemes still need
to be validated for proper functionality as described in Step 4.
the proper synchronization logic is in place and the Gray-encoding
checks have been done, the next step is to verify that there is no data
loss while transferring data from one clock domain to the other. This
needs to be checked for the following two cases:
- Synchronous clock domain crossings
- All fast to slow crossings
- Slow to fast crossings where the clock edges can be close together for continuous cycles
- All asynchronous clock domain crossings
These can be validated by asserting that each source data launch is always captured in the destination domain.
the case of fast to slow synchronous clock domain crossings, where a
synchronizer is not required and for the simple cases of multi-flop
synchronization, check that after every transition on the source data an
active edge of the destination clock arrives where there is no setup or
For other synchronization schemes, some standard
functional checks can be done to ensure that there is no data loss,
which are described in Step 4.
cases, where some special synchronization schemes are used, it is
necessary to verify that they are performing the intended function
correctly. This is important to ensure that there will be no
metastability, data incoherency or data loss problem.
The required checks are given here for three commonly used schemes:
- Handshake synchronization: Check that the request-data and request-acknowledge protocols are working as per the specifications.
- FIFO synchronization: Check that there is no FIFO overflow or underflow.
recirculation: With reference to Figure 8, check that while the
synchronized control signal EN_Sync is active, the following two
- Source data A[0:1] is stable, and,
- at least one active edge of destination clock arrives
The methodology described in the above four steps is also depicted in Figure 16.
Figure 16. Verification methodology
verification methods like simulation and static timing analysis are not
sufficient to detect all types of problems which can occur in clock
domain crossings. The problems which can occur depend on the types of
clock domain crossings. Similarly, the solutions to those problems are
also different and hence the verification techniques required are
different as well. Some of the basic problems of clock domain crossings
have been discussed here. The solutions to those issues are also
discussed and a verification methodology is proposed which will ensure
that data is correctly transferred across clock domains.
 Sanjay Churiwala, “Tackling multiple clocks in SoCs”, EE Times March 15, 2004.
 Shaker Sarwary, “Solving the toughest problems in CDC analysis”, EE Times August 28, 2006.
 K. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, Boston, 1993.
About the Authors
Saurabh Verma Is an engineering manager at Atrenta. He has a bachelor degree from Indian Institute of Technology, Kanpur.
S. Dabare Ashima is a Consulting Applications Engineer at Atrenta. She
has a masters degree from Indian Institute of Technology, Delhi.
If you found this article to be of interest, visit EDA Designline
where you will find the latest and greatest design, technology,
product, and news articles with regard to all aspects of Electronic
Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your
inbox by signing up for the EDA Designline weekly newsletter – just Click Here
to request this newsletter using the Manage Newsletters tab (if you
aren't already a member you'll be asked to register, but it's free and
painless so don't let that stop you).