Scribd
Upload
70 views5 pages

Clock Domain Crossing

This document discusses clock domain crossing (CDC) issues that can occur in system-on-chip (SoC) designs with asynchronous clocks and describes approaches to verifying CDC correctness. Metastability and signal glitches at asynchronous boundaries can cause defects. Verifying CDC for an entire SoC is challenging due to the large design size and number of clock domains. Hierarchical and bottom-up verification approaches are recommended to make CDC verification more manageable for complex SoCs.

Uploaded by

Sam Honey
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
70 views5 pages

Clock Domain Crossing

This document discusses clock domain crossing (CDC) issues that can occur in system-on-chip (SoC) designs with asynchronous clocks and describes approaches to verifying CDC correctness. Metastability and signal glitches at asynchronous boundaries can cause defects. Verifying CDC for an entire SoC is challenging due to the large design size and number of clock domains. Hierarchical and bottom-up verification approaches are recommended to make CDC verification more manageable for complex SoCs.

Uploaded by

Sam Honey
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Clock Domain Crossing (CDC)

Asynchronous communications across boundaries

Description

As design sizes continue to grow, proliferation of internal and external protocols, along with
aggressive power requirements are driving an explosion in the number of asynchronous clocks in
today’s SoCs. This demands that design and verification teams spend an increasing amount of
time verifying the correctness of asynchronous boundaries in the design. Incorrect asynchronous
boundaries can lead to multiple design defects not encountered in simpler designs.

Metastability is one of the major defects. A flip-flop has metastability issues if the clock and data
change very closely in time, causing the output to be at an unknown logic value for an
unbounded period of time. While metastability cannot be eliminated, it is usually tolerated by
adding a multi-flop synchronizer to control asynchronous boundaries and using those
synchronizers to block the destination of an asynchronous boundary when its source is changing.
FIFOs, 2-phase and 4-phase handshakes are typical structures used for this type of
synchronization.

Glitches on asynchronous boundaries can also cause defects, since a glitch on an asynchronous
crossing can trigger the capture of an incorrect signal transition. Data coherency issues occur in a
design when multiple synchronizers settle to their new values in different cycles and
subsequently interact in downstream logic. The list goes on. While the concepts and
methodologies for verification of such issues have been extensively researched in the past ten
years, practical solutions have been offered primarily at the IP-level. Little work has been
attempted to tackle clock domain crossing (CDC) verification signoff of large system-on-chip
(SoC) designs.

Examples of CDC Issues:


1) Data Loss in Fast to Slow Xfer

2) Improper Data Enable Sequence

3) Re-Convergence of Synced Signals


4) Reset Synchronization

CDC for IP Blocks


CDC analysis at the IP level requires some care – there are multiple factors related to which
clocks are truly asynchronous, which clocks can be simultaneously active, which crossings are
allowed to operate without standard synchronizers (for example, configuration signals which are
known to be static through most of the operation of the system) and more. All of this is very
manageable at the IP level but can quickly become overwhelming at the SoC level without a
disciplined methodology.

CDC for Entire SoC


For a typical SoC (as shown below) you often have multiple peripheral interfaces, high
performance internal compute engines, accelerators and bus fabric, hence multiple clock
domains, also multiple power domains and, quite probably, dynamic voltage and frequency
selection in several of these domains. Approaching CDC analysis of this system requires a
systematic methodology.
Sample SoC Architecture

Flat SoC Verification


In flat SoC verification, the entire SoC is verified in a single run. Flat SoC verification covers all
the critical issues briefly described above: Metastability, glitches and loss of coherency in
addition to functional requirements of the asynchronous interfaces and other critical issues across
data, control, clock and reset circuitry. The size and complexity of a design is no excuse for
missing a CDC bug.

The main advantage of flat SoC verification is setup simplicity. Typically, clocks, modes and
other design constraints are available at the chip level, and therefore design setup for CDC
verification is straightforward. This is a significant advantage as proper setup is key to effective
CDC verification and can avoid long signoff iterations.

There are several disadvantages to flat CDC verification for large SoC. Performance is first and
foremost as the analysis doesn’t scale across large designs. Additionally the number of issues
identified can be overwhelming. Additionally, SoCs are sometimes assembled late in the design
cycle. When this is the case, identifying critical CDC issues after assembly will lead to multiple
long iterations between block design and SoC assembly which could impact the schedule and
quality of the SoC implementation.

There are several common practices to address the challenges of CDC analysis at the SoC level.
They include:

 Hierarchical Bottom-Up CDC Verification


In hierarchical bottom-up CDC verification, each block is verified as a part of verification
signoff. As blocks are assembled to build subsystems and finally the SoC, verification is
scaled to the subsystem or SoC level, leveraging the information available from the
verification of blocks previously verified.
 Hierarchical Top-Down CDC Verification
It is becoming increasingly common to pipeline SoC development, so that top-level
assembly starts while at least some IPs are still in development. In such a design flow,
early availability of constraints for the SoC can be leveraged for effective top-down CDC
verification. Here, CDC verification can be applied to the top level design and the top
CDC requirements can be propagated down to blocks, or to inter-block boundaries. This
is different from a flat SoC verification in the sense that while block content may not be
known, boundaries and owners are known; and those owners can use this information to
mature their block designs.

Other considerations:

 Regression flows versus one-time-signoff: Regression flows lend themselves to


incremental verification, and for this you may consider hierarchical flows preferable to a
flat flow. You should also remember that CDC verification has a structural component
and a functional component. The functional component is based on formal analysis so is
typically best suited to block-sized RTL. If functional CDC analysis is important to you,
this may be best accommodated in regression with a hierarchical flow.
 RTL signoff versus netlist signoff: If RTL verification is properly closed, you may not
need to re-verify the netlist from scratch. The main issues that arise at the netlist level are
often due to either design transformations (such as synthesis or power reduction
transformations), or additional design changes such as power intent implementation at the
netlist level which is captured in UPF/CPF in the front end. If full verification of the
netlist is required (e.g., RTL was not verified or transformations are such that full signoff
is justified), then flat SoC verification may be a faster approach.
 Verification time: Flat verification as a whole will take longer than individual iteration
in a hierarchical flow. Assuming block verification has already been completed, you can
iterate top-level verification much more quickly.

Page contents originally provided by Atrenta

You might also like