Knowledge Center

Knowledge Center

Clock Domain Crossing

Asynchronous communications across boundaries


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

Related Entities

Related Technologies

Advertise Here
Advertise your products or services directly

Advertise Here
Advertise your products or services directly



We want to hear from you. If you have any comments or suggestions about this page, please send us your feedback.