Semiwiki 400x100 1 final
WP_Term Object
(
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 4047
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 4047
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)
EDA
Posted on by Daniel Payne

An Approach to Clock Domain Crossing for SoC Designs

An Approach to Clock Domain Crossing for SoC Designs
by Daniel Payne on 07-06-2014 at 12:20 am
Categories: EDA

Blogger Pawan Fangaria wrote about Clock Domain Crossing(CDC) a few weeks ago, and so I followed up tonight and watched a webinarabout CDC presented by Ravindra Anejaof Atrenta. An RTL design engineer would ultimately want a CDC verification tool that offers:

  • Fast throughput and thoroughness
  • Ability to debug and fix the source of CDC errors
  • Handle billions of gates and be considered a signoff tool

Semico Research Group has surveyed SoC designers and graphed out the importance of IP re-use both at the block and sub-system levels.

Even when you buy 3rd party IP, there is some verification required as you use and assemble them all together. Using hundreds of IP blocks can easily introduce asynchronous clock boundaries that require verification.

Here’s a diagram showing two flip-flops driven by two clocks Ck1 and Ck2, where the intended function is for output D0 to propagate to C0 in a stable manner before Ck2 goes high. Signal C0 is arriving asynchronously to Ck2, which is the crux of the CDC problem.

A typical SoC may contain over 100 hundred different clock domains, with over 10,000 asynchronous data crossings, so some automated method is required to find and verify these prior to tape out. Using just RTL simulation to uncover CDC failures is time consuming, error prone and not a guaranteed approach. Four typical CDC bug classes are:

  • Data loss in a fast to slow transfer
  • Improper data enable sequences
  • Re-convergence of synced signals
  • Reset synchronization

The SpyGlass CDC tool has six features to address the verification issues by providing:

[LIST=1]

  • Simple setup – low learning curve, works with standard files and methodologies
  • Signoff QoR – structural and functional checks don’t miss anything
  • Performance – run time results in a reasonable amount of time
  • Low noise – data results are clear to understand and take action, fewer false positives
  • Intuitive debug – shows you where to fix the CDC bugs
  • Hierarchical – accepts the largest design sizes by exploiting hierarchy

    Setup

    A standard file format used by Static Timing Analysis (STA) tools like Primetime from Synopsys is the Synopsys Design Constraints (SDC) file. You get to re-use your SDC files with SpyGlass CDC, and it will even extract all of your clock domains and relationships from the RTL source code itself, identifying potential constraint conflicts in each SDC file.

    Signals in a design are automatically analyzed and can be categorized as static, therefore not required for CDC verification.

    QoR

    Structural tests ensure that your design is verified for metastability by identifying all synchronizers, ensuring that the logic is glitch-free, and that any convergence path will work. Clocks and reset logic are also analyzed to ensure correct operation. Functional tests are performed to ensure that all CDC protocols are being adhered to, using both simulation and formal-based approaches.

    The Unified Power Format (UPF) methodology is also supported, and UPF files are another input for analysis.

    Performance

    There’s a natural engineering trade-off between QoR and performance, so you get to decide which is most important based upon your design flow. There’s even a CDC-Express option that runs just the essential structural tests and thereby achieves a 2X to 5X faster run time than a signoff quality analysis.

    Low Noise

    Understanding the difference between real CDC issues and potential issues is important to keep the results relevant, instead of overwhelming. SpyGlass CDC reduces this noise by performing CDC analysis in a protocol independent manner, finding complex logic like FIFOs, removing quasi-static signals from analysis, and handling converged outputs.

    Debug

    You get to see why there is a failure by clicking on a report and viewing your RTL logic with messages that explain what needs to be fixed.

    Hierarchical

    SoC designs are inherently hierarchical, so it’s a bonus to use a CDC tool that supports both bottom-up or top-down hierarchical analysis. Other CDC approaches force you to flatten your design before any analysis can take place. If you run CDC analysis on each IP block first, then that will minimize the verification effort required for CDC analysis at the SoC level. Even late stage design changes are dealt with quickly by using a hierarchical CDC design flow.

    Summary

    Atrenta has been offering helpful tools to RTL designers since 2001, and their offering for CDC looks to be well accepted in the SoC design community because of the rich features. View the full 48 minute webinar at their web site, after a brief registration process.

    lang: en_US

    Share this post via:

    • Comments

    There are no comments yet.

    You must register or log in to view/post comments.