See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/353331694

FIVE STEPS TO QUALITY CDC VERIFICATION

Technical Report · July 2012

CITATIONS READS
2 2,827

1 author:

Ping Yeung
NVIDIA
31 PUBLICATIONS 47 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Functional Safety View project

Formal Verification View project

All content following this page was uploaded by Ping Yeung on 19 July 2021.

The user has requested enhancement of the downloaded file.

FIVE STEPS TO QUALITY
CDC VERIFICATION

PING YEUNG PH.D., MENTOR GRAPHICS

W H I T E P A P E R

F U N C T I O N A L V E R I F I C A T I O N

w w w . m e n t o r . c o m
Five Steps to Quality CDC Verification

INTRODUCTION
With the number of clock domains increasing in today’s complex ASIC designs, the ability to thoroughly verify clock
domain crossings (CDC) has become even more important. As in functional verification, to ensure CDC issues are
thoroughly verified, a comprehensive test plan is essential. Based on our experience working with many customers,
we developed a five-step planning process for CDC verification.

After having a CDC test plan, an effective CDC verification methodology should include structural, protocol, and
metastability verification. This ensures that CDC signals are handled reliably at the design stage, avoiding costly
respins after they are fabricated. We will outline how these are applied to block-level and top-level RTL modules.
We will describe a few common CDC violations and the techniques used to determine whether they are real design
issues or not. Finally, we will summarize and highlight the results of applying this methodology to a few designs.

METASTABILITY
When a single-bit CDC signal is sampled by a register in a different clock domain, the output of the register can
change at any time with respect to the clock of the receiving register. In hardware, if the value of the CDC signal
changes during the register’s setup or hold time, the register may output a voltage level between 0 and 1. When
this occurs, the register is said to be metastable [1, 2]. The output of a metastable register will eventually settle to
either 0 or 1. However, which value the register settles to is, for all practical purposes, unpredictable.

Figure 1: Metastability.

CDC SYNCHRONIZER
A CDC synchronizer is a subcircuit that conditions the CDC signals to prevent metastable values from propagating
into the rest of the design [1, 2]. A typical two-register synchronizer is shown in Figure 2.

Figure 2: A two-register CDC synchronizer.

w w w. m e nto r. co m
2 [ 1 5]
Five Steps to Quality CDC Verification

CDC synchronizers are used to reduce the probability of metastable signals. Taking unpredictable metastable sig-
nals and creating predictable behavior, they prevent metastable values from reaching the receiving clock domain.

METASTABILITY EFFECTS
Even when proper CDC synchronizers are used for all clock-domain crossings and all CDC protocols are correctly
implemented, metastability inevitably leads to unpredictable cycle-level timing [4, 5]. Traditional RTL simulation
does not model metastability, therefore, it cannot be used to find functional problems that may arise when
metastability manifests in hardware. We are going to show two scenarios in which the cycle-level timing of RTL
simulation differs from the cycle-level timing of the actual hardware in the presence of metastability.

In Figure 3, the incoming CDC signal, cdc_d, violates the register setup time. Although it is sampled correctly in RTL
simulation, the register is metastable and the output settles to 0. As a result, the hardware transition is delayed by
one cycle.

Figure 3: Setup time violation: hardware transition is delayed by one cycle.

In Figure 4, the incoming CDC signal, cdc_d, violates the register hold time. In RTL simulation, it is not sampled until
the next cycle. However, the register is metastable and the output settles to 1. As a result, the hardware transitions
one cycle before simulation.

Figure 4: Hold time violation: hardware transition is advanced by one cycle.

w w w. m e nto r. co m
3 [ 1 5]
Five Steps to Quality CDC Verification

CDC VERIFICATION
Many designers know that metastability can be controlled using synchronizers on CDC signals. The most common
solution is to use synchronizers made up of two D flip-flops (2-DFF), or more, in sequence to dramatically increase
the mean time between failure (MTBF) of the crossings. It is important to point out that simply ensuring the
presence of synchronizers on the appropriate signals, while necessary, is not nearly sufficient. There are three
different aspects of CDC verification that must be carefully addressed:

■ Structural verification. Each synchronizer must have the correct structure for the type of signal being sent across
clock domains. For example, a 2-DFF synchronizer is usually the best solution for single-bit signals but should not
be used for multi-bit signals unless they are gray-coded to ensure that only one bit changes at a time [1, 2]. Multi-
bit signals may be synchronized across domains using a separate control signal, an asynchronous FIFO, or other
methods. Also, there should be no combinational logic inside or before a synchronizer.
■ Protocol verification. Each synchronizer must follow a set of rules, called a transfer protocol, to ensure that the
CDC signal is properly transferred across clock domains. For example, even the simplest 2-DFF synchronizer
requires that the transmitting signal be held stable long enough to guarantee that it is captured in the
receiving domain. This may not occur if the transmitting clock is faster than the receiving clock.
Synchronization structures for multi-bit signals require more complex protocol checks [2, 3]. When CDC
transfer protocols are violated, an error may not occur in simulation but will eventually occur in real hardware.
■ Metastability verification. Problems associated with the reconvergence of CDC signals must be avoided.
Reconvergence occurs when multiple signals are synchronized separately from one clock domain to another
and then used by the same logic in the receiving domain (Figure 5). If that logic assumes a timing relationship
between the signals, the design is not tolerant of metasta bility and will eventually fail [4, 5]. This is because
the purpose of synchronizers is to “fence in” metastability to ensure that unpredictable values are not seen by
the receiving logic; yet metastability will still occur within each synchronizer, causing unpredictable delays on
CDC signals.

Figure 5: Reconvergence of CDC signals.

Traditional CDC verification methods include manually inspecting RTL code for the presence of synchronizers,
running full timing simulations, sweeping clocks against each other, and using special simulation models to ran-
domly vary the delays through synchronizers. These methods find only a subset of the errors in a given design.
Fortunately, the Mentor Graphics Questa® CDC tool and methodologies [7] are now available to exhaustively
analyze your RTL and, integrated with simulation, find all the types of CDC problems described so far.

w w w. m e nto r. co m
4 [ 1 5]
Five Steps to Quality CDC Verification

FIVE-STEP PLANNING PROCESS

As companies start to recognize the importance of CDC verification,
they are deploying automated solutions to tackle this complex
problem. However, when verification teams jump right into the tools
without any planning, very often the results are far from satisfactory.
Design knowledge is essential and the verification approach has to be
in-tune with the clock structure. Over-simplified analysis of all CDC
paths may result in a lot of issues and violations. As the “noise” level is
high, potential problems can easily be overlooked. Based on our
experience working with many customers, Mentor Graphics has
developed a five-step planning process that addresses and helps
minimize this initial noise.

Before performing the actual CDC verification, you should follow this
planning process to identify potential candidate blocks, document
CDC requirements, formalize exceptions, define coverage goals, and
select a verification strategy. The information required for these steps
should already be in the design specifications. Otherwise, a design
overview meeting should be held; using the five-steps as the meeting
agenda, you can gather the required information before embarking
on the actual CDC verification.

IDENTIFY POTENTIAL CANDIDATE BLOCKS

It is important to know where, and where not, to apply CDC
verification. The ideal candidate are blocks with multiple Figure 6: Five-step process for CDC verification.
asynchronous clocks.

In order to perform structural verification, the tool has to understand the internal structure of the design. Unsynthesiz-
able logic (such as pads, clock generators, and memory modules) and non-functional logic (such as JTAG, BIST, scan,
and power controls) should be either skipped entirely or labeled as black boxes for CDC verification. Hence, running
CDC verification at the chip-level is not ideal as there
are too many behavioral models.

For this reason, designs with the RTL representation

are best suited for CDC verification. All multiple-bit
registers and buses can be identified explicitly. As
CDC requirements for data and control signals are
different, they can be analyzed separately.
Conversely, with a gate-level representation, all
buses have been synthesized into single-bit wires. It
is impossible to distinguish data from control signals.
Thus, only a subset of the CDC scheme is applicable.

In addition, knowledge of the internal structure of

the design is essential for successful CDC
verification. Performing CDC analysis on third-party
IP blocks or legacy designs are not very beneficial.
Without design knowledge, you may not be able to
confirm the bugs or filter violations. You need access
to the original designer; knowledge of the design is Figure 7: Blocks suitable for running CDC verification are A, C, and D.
essential to understand the results.

w w w. m e nto r. co m
5 [ 1 5]
Five Steps to Quality CDC Verification

DOCUMENT CDC REQUIREMENTS

This step is important. It has the biggest impact on the quality of the result. You need to ensure that your CDC
verification will be aware of all relevant design characteristics, clock relationships, and the external environment.
Although a set of CDC rules have been defined already in the tool, with this additional information, extra design
rules and filters will be activated. As a result, the results will be more accurate and thorough. You should define the
operational modes of the design, outline the clock structures, document the domains for interface signals, and
determine the acceptable or unacceptable synchronization rules.

Define operational modes. Some users may be interested in verifying that all registers are driven by only the test
clock when the design is in scan mode. However, in general, we want to perform CDC verification when the design
is in normal operation. You should disable the non-functional modes (i.e., test, BIST, JTAG, etc.) and define the
meaningful operational modes and configurations for the tool (Figure 8). In many cases, some parts of a design can
be put into sleep or powered-down mode. The combinations can be countless. Hence, it is important to focus CDC
verification on the important combinations.

Outline clock structures. For a multiple-clock design, the primary clocks, the clock distribution structure, and the internal
clock generators, dividers, and clock gating schemes are important and should be documented. The Questa CDC tool [7]
can understand these structures and extract the clock tree information automatically. It is useful to verify the original
design intent with the extracted clock structures. Only crossings between asynchronous clocks should be analyzed, and
there may be clock gating conditions that need to be set up properly. As the number of CDC paths is proportional to the
number of clock domains, it is much more efficient to limit analysis to the relevant clock domains only.

Figure 8: Define meaningful modes for CDC verification.

■ Document interface signals. CDC verification will not check an interface signal if it does not know which clock
domain it is coming from or fanning out to. You should group signals for each functional interface and clock
domain and explicitly identify any input signals that are asynchronous to all clock domains. The tool will then
determine whether input signals require synchronization before use. Asynchronous and synchronous reset
signals should be labeled separately. The synchronization schemes used for reset signals are different from
normal interface signals.
■ Define synchronization rules. Some companies require all CDC signals to be synchronized with a particular CDC
scheme (for instance, 3-level DFFs) or with a custom synchronization cell. The Questa CDC tool [7] recognizes
many CDC schemes. It is important to review those schemes first. Then you can categorize the legal or illegal
synchronization schemes, turn off the unused schemes and capture the characteristics of the synchronization
cells or modules.

w w w. m e nto r. co m
6 [ 1 5]
Five Steps to Quality CDC Verification

Some detail oriented designers will specify the clock domain information and capture the CDC paths in the design
document. This is a practice we encourage. With this information, you can pay special attention to the specified
CDC paths to ensure they are well covered.

FORMALIZE KNOWN EXCEPTIONS

It is not unusual that a simple CDC error will generate a lot of violations, especially when the CDC signal fans out to
a large number of asynchronous domains. Hence, we want to identify upfront all registers that can be considered
stable and do not require synchronization. This is especially true for configuration registers, status registers, or
control registers that are programmed by software before the design enters into normal operation. Usually this
information is in the design specification. Often these control registers all reside within a single module or follow a
common naming scheme. It is useful to leverage this information for CDC verification.

In addition to registers, some of the interface or internal signals are known to be stable during normal operation;
for example, the internally generated reset signals, the power-down signals, the chip select, and functional enable
and disable signals. These are all useful in improving the efficacy of CDC verification. Finally, in previous revisions of
the chip, there may be known CDC bugs and issues found using manual or gate-level methodologies.. These are
painful lessons which should be captured in the verification plan. During CDC verification, you should ensure that
those CDC paths are analyzed and that all problems were fixed correctly.

DEFINE COVERAGE GOALS

Based on our experience, CDC paths are poorly verified by traditional functional verification because, in a functional
simulation environment, the clock periods are defined to be constants, the clock skews and relationships are fixed,
and the clock signals are well-behaved without any buffer or propagation delay. To ensure metastability effects on
CDC paths are better verified, companies use various adhoc approaches. Some randomly reduce or prolong the
clock periods. Some randomly change the skews and relationships among multiple asynchronous clocks.

Regardless of the technique used, when verifying CDC transfer protocols in simulation, it is important to monitor
protocol coverage to make sure the CDC paths are adequately verified. This can be done by using a checker from
an assertion library [9, 10, 11] to capture the semantics of the protocol. Checkers collect coverage information to
ensure that each CDC protocol is fully exercised. Insufficient coverage means that the design may contain
undiscovered bugs.

CDC Handshake:
- Assertion:
i. multiple requests violation
ii. acknowledge without request violation
iii. request drop violation
iv. acknowledge timeout violation
- Coverage:
i. #request asserted
ii. #acknowledge asserted

CDC FIFO:
- Assertion:
i. FIFO overflow violation
ii. FIFO underflow violation
iii. Simultaneous push and pop violation
- Coverage:
i. #push asserted
ii. #pop asserted
iii. maximum FIFO entry

w w w. m e nto r. co m
7 [ 1 5]
Five Steps to Quality CDC Verification

You start by itemizing the protocols used in the CDC paths, ordering them from most important to least, and
identifying the protocols that require coverage. For each CDC protocol, you will determine the assertion and
coverage items, as in the code shown above. To measure how well your simulation is verifying the metastability
effects, you should also monitor the alignments of the RX and the TX clocks.

SELECT A VERIFICATION STRATEGY

You may choose to perform exhaustive verification on each individual block or use a hierarchical approach on the
entire top-level of a chip. The top-level represents the highest functional hierarchy of the design, excluding the pad
ring, the test logic, the power controls, etc. You may be looking for a known bug or hunting for a problem that has
appeared in the lab. The strategies you choose will determine how to run your CDC analysis tools. Based on our
experience, there are four common strategies

■ Block-level verification. During block-level design, static analysis of the CDC structures should be run before
checking in the RTL code. This ensures strict compliance with CDC schemes. If issues are discovered, they can
be identified and debugged quickly at this level. The generated CDC protocol monitors can also be used with
block-level functional verification methodologies, such as formal verification [8] and simulation. These ensure
that CDC protocols are followed without any data loss.
■ Top-level verification. During top-level integration, static analysis of the CDC structures should be rerun to
check the new CDC signals created when multiple blocks are integrated together. The number of CDC signals
goes up exponentially at the top-level. Hence, it is important to follow the five-step planning process
described above. For large and complex designs, especially ones with a lot of IP modules, a hierarchical veri-
fication approach can be used. The generated CDC protocol monitors should be included in the regression for
system-level functional verification.
■ Bug hunting and triage. This is performed to identify known or suspected CDC issues in the design. It is
important to distinguish timing from CDC issues. Timing issues tend to cause the chip to fail consistently. By
changing the frequencies of the clocks or of some of the signals, the problems may disappear permanently.
On the other hand, as metastability is unpredictable, CDC problems will cause the chip to fail randomly. Based
on our experience, it is extremely difficult to look for CDC issues at the system or chip level. There are just too
many potential candidates. Hence, the first task is to narrow down the problem to the block or subsystem
level. You should focus on blocks with asynchronous clock domains. Blocks with CDC reconvergence are
especially suspicious. The random delays from different CDC paths may cause the data to be sampled
incorrectly or corrupted completely. Once the candidate blocks are identified, the block-level verification
strategy can be applied.
■ Targeting coverage. This can be an extension of the block-level or top-level verification strategy. The goal is to
ensure that all CDC protocols have been fully exercised and that the metastability effects are fully verified on
all CDC paths. The coverage on the CDC protocols monitors should be examined and additional tests created
to fill any coverage holes. Once the bug rate of system-level regression has stabilized, metastability can be
injected into simulation. Metastability effects will change the timing of the CDC paths. If the block is not
designed to handle the random delays of the CDC paths, it may fail functionally. To make debugging easier, it
is better to start with a representative subset of the regression.

In the next two sections, we will elaborate on the two most commonly used strategies: block-level and
top-level verification.

w w w. m e nto r. co m
8 [ 1 5]
Five Steps to Quality CDC Verification

BLOCK-LEVEL CDC VERIFICATION

Figure 9: Block-level CDC verification flow. Numbers correspond to text.

1. Run structural verification with static analysis. This step builds a netlist of the target design, performs static
analysis on the netlist, and uses the information gathered in the planning steps to produce the correct results.
You should get a report of all clock domains and all properties of I/O signals and, most importantly, a
summary of all CDC paths in the design, divided into the following categories:
– Correctly implemented synchronizers
– Missing and incorrectly implemented synchronizers
– Complex synchronizers that require protocol verification
– Potential reconvergence problems

At this level, since the design description is small, most of the CDC paths fall into the correct or incorrect
categories. These results can then be viewed in the GUI environment. A schematic of the CDC path can be
generated so that any issue can be debugged easily.

2. Run protocol verification with formal analysis. Structural verification will generate a collection of monitors for the
CDC transfer protocols. At this level, since we may not have a testbench environment to run simulation, formal
verification can be used to verify the CDC protocol monitors. Formal verification [8] uses a simple reset
sequence to initial the design. Then, based on the specified clock periods of the asynchronous clocks, it
performs cycle-based analysis of the design. If a monitor is proven, it means that the CDC protocol will always
be followed. The remaining monitors can be promoted to system-level simulation. The results can be
combined with the static analysis results, which are viewed within the same GUI environment.

w w w. m e nto r. co m
9 [ 1 5]
Five Steps to Quality CDC Verification

TOP-LEVEL CDC VERIFICATION

Figure 10: Top-level CDC verification flow. Numbers correspond to text.

1. Run structural verification with static analysis. Before running static analysis on the top-level of the design, it is
important to exclude any unsynthesizable or nonfunctional logics. The CDC tool will flatten and build a netlist
of the target design and perform static analysis on the netlist. The CDC requirements (operational modes,
clock structure, interface signals, and synchronization rules) gathered in the planning steps are essential in
guiding the verification process to produce the correct results. You should get a report of all clock domains
and all properties of I/O signals and, most importantly, a summary of all synchronizers in the design, divided
into the following categories:
– Correctly implemented synchronizers
– Missing and incorrectly implemented synchronizers
– Complex synchronizers that require protocol verification
– Potential reconvergence problems

At this level, since the design description contains a lot of modules with a lot of asynchronous clock
domains, most of the CDC paths fall into the complex and reconvergence categories. The GUI environment
is particularly useful in this case as the CDC path may span multiple levels of hierarchy and several modules.

w w w. m e nto r. co m
10 [1 5]
Five Steps to Quality CDC Verification

2. Run protocol verification with simulation. With the testbench environment already available for functional veri-
fication, we can run the CDC protocol monitors within the simulation environment. These monitors ensure
that the CDC signal is stable when going from the TX to the RX domain; the multiple-bit CDC data is gray-
coded, or it is stable when it is sampled. Any assertion failure caught by the monitors means that the CDC
protocol is violated and should be fixed. Functional simulation gives lengthy margins for CDC signals. They
tend to be sufficiently stable when going through the clock domains. This approach does a poor job stressing
the timing of the CDC paths. Hence, when running CDC protocol monitors with functional simulation, it is
important to examine the corner case coverage of the protocol monitors. Monitors which pass should have
adequate coverage when the results from the whole regression suite are merged together. In order to stress
the timing of the CDC paths explicitly, we can add some direct tests into the regression suite. With a
constrained-random verification environment, we can tighten the timing of the stimulus generator.
3. Run metastability verification with simulation and effect injection. If your design contains potential reconver-
gence violations that cannot be easily waived after manual inspection, the Questa CDC tool [7] can be used to
identify reconvergence problems by injecting metastability effects dynamically. In simulation, metastability
effect injectors will change the delays through synchronizers. As a result, any logic that assumes a fixed timing
relationship between the outputs of the synchronizers is likely to fail. Running simulation with the effect
injectors is the most cost effective way to imitate CDC metastability effects during functional verification. It
enables any potential problems to be discovered quickly, before any hardware is built.

DEBUGGING CDC VIOLATIONS

In this section, we will describe a few common CDC violations and the techniques you can use to determine
whether they are real design issues or not.

MISSING SYNCHRONIZER VIOLATION

An unsynchronized CDC signal is the most common violation reported during structural verification. For instance,
in Figure 11, depending on the clock frequency, the RX register may not be able to sample its input reliability. This
is a real problem. In other cases, violation are due to the following exceptions.

Figure 11: Missing synchronizer violation.

w w w. m e nto r. co m
11 [1 5]
Five Steps to Quality CDC Verification

POTENTIAL EXCEPTIONS:
■ The unsynchronized path is a false path. For instance, the multiplexer in Figure 11 will never select the
unsynchronized path shown in normal operation. To correct this in future analyses, the operation modes from
planning Step 2 should be used to configure the multiplexer.
■ The TX register contains a stable value. Hence, a synchronizer is not required. In this case, we can validate the TX
register with the known exceptions in planning Step 3. If yes, we can identify this stable register for the tool.
■ The unsynchronized signal is sampled via a synchronized signal. For example, the multiplexer in Figure 11 is
controlled by a synchronized signal. Hence, as long as the unsynchronized signal is stable while sampled, it
will cross the clock domain correctly. The Questa CDC tool [7] has been enhanced to check for this.
■ The unsynchronized path may be part of an adhoc synchronization scheme. If this adhoc scheme is allowed
as a design policy, you will tell the tool to ignore this path in the future.

COMBINATIONAL LOGIC VIOLATION

Combinational logic in a synchronization path is a significant problem for synchronized signals, because the data
used to determine an acceptable failure rate on CDC paths assumes a single transition within each clock period. But
if combinational logic is on the path, as in Figure 12, glitches will be generated. As a result, the error rate rises
significantly. To address this problem, you should remove all combinational logic from the logic path. In some
cases, there are exceptions.

Figure 12: Combinational logic violation.

POTENTIAL EXCEPTIONS:
■ The combinational logic is constant during normal operation, so glitches cannot be generated. To incorporate
this into future analyses, the operation modes from planning Step 2 should be used to configure the
combinational logic.
■ The combinational logic will transition only once per clock. For example, in Figure 12, the inputs to the
combinational logic are all stable except the TX register. Hence, the output of the combinational logic is
unlikely to glitch. We can provide this information to the tool for future analyses.
■ Very often combinational logic is simply a buffer. It is not a problem; the Questa CDC tool is designed to
ignore buffers and inverters.

w w w. m e nto r. co m
12 [1 5]
Five Steps to Quality CDC Verification

RECONVERGENCE VIOLATION
Reconvergence occurs when the fan-in of a flip-flop includes two separately synchronized CDC signals from a
different clock domain. When synchronized CDC signals reconverge, their relative timing is unpredictable. The data
from the two CDC paths may not arrive at the same time. Logic that receives these signals should account for
potential cycle skew. Otherwise incorrect data may be generated for the downstream logic. As in Figure 13, if the
value in one CDC path arrives before the other, the multiplexers will be out of sync and an incorrect value will be
clocked into the RX register.

Figure 13: A reconvergence violation.

POTENTIAL EXCEPTIONS:
■ The reconverged CDC paths are mutually exclusive. For example, in Figure 13, the CDC paths may be from two
different interfaces that will not turn on together. In that case, there is no need to worry about the relative timing
between them. To verify their exclusive behavior, an assertion [6] can be used with simulation or formal verification.
■ The reconverged CDC paths may have a large guard time between changes. This is similar to exclusivity. In this
case, we can defer them to metastability verification.

The seriousness of a reconvergence violation can be determined precisely with metastability verification. If a
simulation failed with metastability effect injection, then the reconvergence violations will cause serious problems
in hardware.

The best way to visualize the effect of the metastability injectors is with a waveform comparison tool. In Figure 14,
the original simulation is compared with one from metastability verification. As random delays are introduced into
the CDC paths, the CDC signals will be advanced or delayed by one clock cycle. These are highlighted by the one-
cycle differences in the waveform (in the middle section of Figure 14). If the design can handle these one-cycle
skews, the waveform will match up again quickly. If the design cannot handle these skews, incorrect values will
propagate through the receiving logic, leading to massive differences between the two waveforms (on the top
section of Figure 14).

w w w. m e nto r. co m
13 [1 5]
Five Steps to Quality CDC Verification

Figure 14: Comparing original simulation with metastability effect simulation.

CDC VERIFICATION RESULTS

We have recommended and applied the five-step planning process to a large number of designs. We highlight
some of them in this section.

At the block level, there are not a lot of clock domains normally. In most cases, there are only two to three clock
domains. In the wireless application (Table 1), it is a block with a number of asynchronous interfaces. Hence, there
are eight clock domains. As the number of CDC signals is manageable, debugging is straightforward. From the
results, we can see that most of the issues are related to synchronizers.

Design Number of Clock Domains Number of CDC Signals Clock Domain Issues

Combinational logic in
Communication Interface 3 254
synchronizers
12 CDC issues; custom
Wireless Application 8 364
synchronizers
Missing control
Multimedia SoC Design 4 54
synchronizers

Table 1: Block-level results summary.

w w w. m e nto r. co m
14 [1 5]
Five Steps to Quality CDC Verification

Design Number of Clock Domains Number of CDC Signals Clock Domain Issues

Missing and incorrect

Graphics Application 36 – 42 > 18,200
synchronizers
Missing data select
Gigabit Ethernet Interface 24 – 28 > 11,700 synchronizers;
reconvergence problems

Table 2: Top-level results summary.

At the top-level, it is much more challenging (Table 2). The number of clock domains depends on the design
configuration. As a result, we have to define the possible combinations of operational modes carefully and perform
CDC verification on each combination individually. The number of CDC signals is large. We followed the five-step
planning process carefully. Besides the operational modes, we also outlined and reviewed the clock structure with
the design team before running any detailed analysis. At the block-level, the synchronization rules are simple. A
designer will normally use just one or two synchronization schemes. At the top-level, however, there are blocks
from multiple sources. Some of them are external IPs. There is a mixture of synchronization schemes. As CDC
signals are coming from multiple sources, the reconvergence problem is apparent. In both designs, we have found
reconvergence issues. Some of them were confirmed after analyzing the schematic carefully; for others,
metastability verification was performed.

CONCLUSION
The risks of not doing comprehensive CDC verification on today’s ASICs are just too great. CDC verification should
be on the checklist of today’s verification test plan. With the five-step planning process and the availability of EDA
CDC tools [7], CDC verification can now be done at the register transfer level. This allows verification to start earlier
and enables CDC issues to be caught at a level where debugging is more manageable.

The five-step planning process for CDC verification was developed to overcome the adhoc verification process. It
formalizes the information gathering process and encourages design teams to capture this information in the
design document. The five steps are:

1. Identify potential candidate blocks

2. Document CDC requirements
3. Formalize known exceptions
4. Define coverage goals
5. Select a verification strategy

A comprehensive CDC verification strategy should include structural verification with static analysis, protocol
verification with simulation, and metastability verification with effect injection. These can be applied to both the
block-level and the top-level of a design, enabling CDC verification to be integrated seamlessly into the
verification flow.

w w w. m e nto r. co m
15 [1 5]
 Five Steps to Quality CDC Verification

REFERENCES
1. Clifford E. Cummings, “Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Designs,”
SNUG-2001. Downloadable from www.sunburst-design.com/papers
2. Tai Ly, “The Need for an Automated Clock Domain Crossing Verification Solution,” White Paper, Downloadable
from www.mentor.com/fv
3. Chris Kwok, et al, “Using Assertion-Based Verification to Verify Clock Domain Crossing Signals,” DVCon 2003
4. Tai Ly, et al, “Formally Verifying Clock Domain Crossing Jitter Using Assertion-Based Verification,” DVCon 2004
5. Tai Ly, et al, “A Methodology for Verifying Sequential Reconvergence of Clock Domain Crossing Signals,”
DVCon 2005
6. Harry Foster, et al, “Assertion-Based Design,” Kluwer Academic Publishers, 2003
7. Mentor Graphics, “CDC Compiler User Guide V2.5,” Feb 2007
8. Mentor Graphics, “Formal Verification User Guide V2.5,” Feb 2007
9. Accellera, “Accellera Standard OVL Library Reference Manual,” July 2006
10. Mentor Graphics, “QuestaTM Verification Library Checkers Data Book V6.2f,” Jan 2007.
11. Mentor Graphics, “CheckerWare Data Book Assertion Library V2.5,” Feb 2007

For the latest product information, call us or visit: w w w . m e n t o r . c o m

©2016 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 8-16 TECH14560-w

View publication stats