Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • Low Power Verification - 4/29
      • Fault Campaign for Mixed-Signal - 5/4
      • User2User - 5/26
      • Webinar Calendar
    • On-Demand Webinars

      • CDC+RDC Analysis
      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • All On-Demand Webinars
    • Recording Archive

      • Siemens EDA 2021 Functional Verification Webinar Series
      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • Industry Data & Surveys
      • All Recordings
    • Conferences

      • DVCon 2021
      • DVCon 2020
      • DAC 2019
      • All Conferences
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2021
      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa Basic
      • Questa Advanced
      • Mastering Questa
  • Home
  • Verification Horizons
  • June 2017
  • RTL CDC Is No Longer Enough — How Gate-Level CDC Is Now Essential to First Pass Success

RTL CDC Is No Longer Enough — How Gate-Level CDC Is Now Essential to First Pass Success

Verification Horizons - Tom Fitzpatrick, Editor

RTL CDC Is No Longer Enough — How Gate-Level CDC Is Now Essential to First Pass Success by Anwesha Choudhury, Ashish Hari, and Joe Hupcey III - Mentor, A Siemens Business

Clock-domain crossing (CDC) verification is a critical step in the design verification cycle. However, CDC verification is not only necessary on RTL; at 28nm nodes and below it is also essential on gate-level designs due to the possibility of the introduction of CDC errors during the synthesis phase that can lead to silicon failure. In this article we review the root cause of these challenges and introduce an automated approach to overcome these difficulties.

INTRODUCTION

CDC verification ensures that signals pass across asynchronous clock-domains without being missed or causing metastability. Traditionally, CDC verification is done on a register-transfer level (RTL) representation of the design. However, during the synthesis stage, when the design is transformed from RTL to gate-level, various new issues can be introduced that may eventually lead to chip failures. So, even after CDC verification closure at the RTL, it is important to perform CDC verification on a gate-level design to detect and address new issues.

Changes introduced in the netlist during synthesis, such as timing optimization of synchronization logic and insertion of design-for-test (DFT) and low-power circuitry may cause incorrect behavior in CDC synchronizers, introduce new CDC paths or break valid CDC paths. For example, new clock-domain crossings can be introduced due to insertion of low-power logic as shown in Figure 1. Similarly, due to scan logic insertion, a clock tree can be impacted if the correct mode design constraints are not specified, as shown in Figure 2.

Figure 1. CDC path impacted by power logic

Figure 2. Clock and data path impacted by DFT logic

Additionally, faulty implementation of combinational logic by synthesis tools may result in glitches on con-trol and data paths. As shown in Figure 3, a valid mux-based synchronizer (3A) is converted to a combinational logic which is logically correct, but can propagate a glitch from asynchronous transmit domain causing chip failure (3B).

Figure 3A. RTL MUX logic, pre-synthesis

Figure 3B. MUX logic converted to combinational logic with glitch

The bottom-line is that even after you have achieved "CDC closure" at the RTL level, CDC-related chip-killing glitches can appear downstream unexpectedly. In short, you thought you were safe, but you are still at risk!

So what can be done about this?

First, tweaking the settings in your synthesis tool can sometimes help prevent this issue in the first place. But based on our experience with numerous customer designs – especially devices at the 28nm node and below – it's clear that the reduced "bandwidth" of these advanced nodes, coupled with the high circuit complexity, makes it virtually impossible for a synthesizer to exhaustively account for all the causal factors and constraints. Consequently, CDC verification at the gate-level is absolutely required in order to ensure all chip-killing glitch-y circuitry is identified and designed out. Unfortunately, the solution is not as easy as simply re-running RTL-centric CDC tools on gate-level netlists.

WHY RTL CDC TOOLS ARE UNSUITABLE FOR GATE-LEVEL ANALYSIS

The most common reasons that make gate-level CDC verification closure a daunting task with RTL-focused CDC tools include:

Significant setup effort: All designs have refined CDC design constraints setup at the RTL with which the design is verified to be CDC clean. These RTL constraints cannot be reused during CDC verification at the gate level because of changes in the module and signal names post synthesis and technology mapping. All design constraints that refer to RTL signals and modules no longer work. Manual conversion of constraints is not feasible as it involves high effort and needs knowledge of name transformations done by the synthesis tool. Writing new setup constraints is not desirable as it requires several iterations to fine-tune the constraints and thus leads to significant delay in the verification schedule.

Glitches can be introduced on CDC paths that were safe at the RTL: As per the earlier example, the most common glitch introduction scenario is when a mux in the data path is transformed as combinational logic that can possibly glitch. This situation requires special approach to identify and fix glitch scenarios.

The design bus signals are split into multiple single-bit signals at the gate-level, causing several issues:

  • Differentiation between data and control signal is lost and traditional CDC verification tools treat every path as a single-bit control path.
  • In general, the design size "increases" as compared to the RTL description, stretching the capacity limits of CDC verification tools.
  • The CDC crossing count increases many times, resulting in high noise, leading to the next point…

Exponentially higher debug effort due to increase in violations and noise:

  • Recall that designers commonly add waivers during CDC analysis at the RTL for acceptable scenarios. However, these waivers -- written on RTL results -- do not work at the gate-level due to signal name and topology changes. This makes gate-level CDC closure much more difficult as now the verification engineer needs to reanalyze and waive CDC paths that were already qualified at the RTL.
  • False violations can increase due to the interference of scan logic. User intervention is needed to correctly specify the functional mode.

At this point, after reading all these depressing limitations of RTL-level CDC analysis you might be wondering why bother to do RTL CDC verification at all. Ironically, the key to effective gate-level CDC verification is successful RTL verification.

PROPOSED GATE-LEVEL CDC VERIFICATION FLOW

As you might expect, the basis of our gate-level solution leverages virtually every element of a successful RTL-level CDC analysis. Specifically, Figure 4 below illustrates a high-level CDC verification flow on RTL to netlist and how to enhance the flow to reuse knowledge about setup and waivers at the RTL for downstream gate-level CDC verification.

Figure 4. CDC verification flow from RTL to netlist

First, RTL CDC closure is one of the necessary RTL sign-off criterion; so assume that every design at the RTL stage will have gone through CDC verification. After the RTL is frozen, the design goes through synthesis and a netlist is generated. As per the warning in the previous section, a fresh CDC run on the gate-level netlist would require huge and painful setup effort that would only yield very noisy results. To address this, the trick is to reuse the constraints and waivers that were created for CDC verification at the RTL level. Specifically, this new flow works on a gate-level netlist along with RTL constraints or gate-level constraints (and/or any SDC files) for the gate-level design. It then employs specially designed gate-level analysis algorithms inside the Questa® CDC Gate-Level app ("CDC-GL"), which infers all the design-mode constraints and detects the scan and test signals. Then, after the user qualifies the setup, the actual CDC analysis on netlist is executed with the Questa® CDC Gate-Level app. Below are the details, in the context of the aforementioned challenges of the conventional approach.

A. Setup Automation: The good news is that all of the constraints created for RTL CDC verification can be provided as-is – Questa® CDC-GL automatically maps RTL constraints to the corresponding gate-level signal and module names that were generated by the synthesis tool. Again, this automation saves tons of effort that would have been needed to create and refine the setup through multiple iterations; plus it also ensures reduced false noise as the constraints are already validated in RTL CDC analysis. An example of this automation is illustrated in Figure 5. The custom synchronizer and quasi-static signal specifications in the RTL are automatically converted to match the gate-level design signal and module names.

Figure 5. Examples of automatic conversion of RTL constraints to gate-level constraints

Note: RTL-to-gate name mapping processing can be expedited by referencing name-mapping files from logic equivalence checking (LEC) run on the synthesized design (Mentor's FormalProTM is one example of such a tool). Additionally, if you have an SDC file, Questa® CDC-GL can also automatically extract important information from the SDC and use it for the gate-level CDC analysis.

The next level of automation Questa® CDC-GL provides is the inference of constraints for the logic that was not present in the RTL but got inserted during synthesis and later stages. For example, DFT logic is inserted later in the flow. However, it is important to verify the CDC design in the right mode, that is, the functional mode. If the tool does not differentiate between test and functional modes, it leads to more gated clocks, and hence extra noise and false crossings. In the proposed methodology, such mode and constant settings are inferred by analyzing the design topology using software algorithms on the design graph. This ensures that the user doesn't have to manually analyze false crossings and constrain the design in the appropriate mode. With the suggested flow, the user just runs the gate-level CDC analysis and reviews the constraint guidance provided by the tool.

An example of the scan logic impacting CDC crossings is shown in Figure 6A. If mode constraints are not specified, then with traditional CDC verification approach, the CDC path will be reported as unsynchronized crossing. However, in the proposed methodology such logic is analyzed to detect scan enable and test mode signals and correct constants are set on them automatically to ensure the design operates in functional mode and synchronizers are detected as shown in Figure 6B. This approach eliminates false noise due to insertion of extra logic, also saves a ton of user effort in specifying the constraints manually.

Figure 6A. DFT inserted CDC path

>

Figure 6B. CDC path with synchronizer in functional mode

>

B. Elimination of Noise in CDC Analysis: Honoring RTL constraints and inferring functional mode constants not only ensures that the setup is correct, but it goes a long way to minimize "noise" in the CDC analysis of the gate-level netlist. However, considerable noise can still come from the splitting of vector signals during synthesis as this leads to a huge increase in the number of reported crossings. The good news is that Questa® CDC-GL understands the splitting of vectors by synthesis and considers this during CDC gate-level analysis to correctly identify the control and data crossings. This identification of data crossings drastically reduces the noise and also brings gate-level results closer to the RTL-level analysis output. In addition, the RTL signal name is reported so that users can correlate gate-level results with RTL results. An example is shown in Figure 7 below. A 16-bit data crossing in the RTL gets converted to 16 individual single-bit crossings in the netlist. In the proposed approach, a single data crossing and its correlation to the RTL crossing is reported.

Figure 7. Data crossing identification

This automation reduces the violation count and guides the user to differentiate between control and data path crossings, and to correlate the results with RTL results.

C. Reuse of RTL Waivers: RTL CDC analysis of even small IPs can require the creation of many waivers, representing a lot of work, often from multiple people. It's imperative that this time is not wasted, and that's why this suggested methodology enables reuse of the RTL CDC run waivers. In short, the crossings qualified by users as stable or false during RTL analysis need not be reanalyzed at the gate-level because the RTL waivers are automatically transformed and applied to gate-level results. This reuse also includes any status information or user comments attached to the RTL waivers are carried forward corresponding gate-level crossings. This ensures that when the user gets the gate-level results for the first time, there is minimal noise and only new issues identified at the gate-level are highlighted.

CASE STUDY

To prove out the new flow, the new gate-level specific methodology and a traditional CDC verification flow were executed on a representative set of customer designs from 1 to 100 million gates. For each design, constraints at RTL were available along with the netlist, and the CDC results, run time and memory consumption were captured for each run. Figure 8 compiles the comparison of this data.

The data is clear: significant improvements were observed in run time, memory, and noise with the new Questa® CDC-GL flow. As you can see, when the traditional approach was tried on these designs it resulted in a very large number of CDC paths. As explained earlier, this was primarily due to inability to reuse the RTL constraints and waivers, missing constraints for the scan logic and splitting of vector signals.

In contrast, because the new flow automatically applied the RTL constraints, inferred scan logic constraints, honored RTL waivers, and smartly considered the impact of splitting of vector signals, the noise level dropped significantly and also led to an average of 50 percent improvement in run time and 15 percent improvement in memory consumption. Consequently, the turnaround time and effort involved in CDC verification closure on these gate-level netlists was significantly reduced, while the quality of results dramatically increased.

We extended the experiments by running CDC analysis on both RTL and gate-level version of the same testcase with the same set of RTL constraints. The gate-level run was executed using name-map file from the LEC tool and the RTL constraints.

Figure 8. Comparison between RTL-Only CDC analysis and New, Optimized Gate-level CDC verification on gate-level netlists from 1 to 100 million gates

CONCLUSION

CDC analysis at gate-level is required – without it, CDC bugs introduced during synthesis can escape leading to chip failure. The suggested methodology using the Questa® CDC Gate-Level app is easy to adopt as it utilizes all the knowledge from the design and RTL CDC verification processes that occur before. The results of the verification come in much faster, and are much higher quality. All of this shrinks the setup, debug, and repair turn-around time of chip killing glitches during one of the most high pressure stages of a project.

REFERENCES

  1. Clifford E. Cummings, "Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog", SNUG-2008
  2. Vishnu C Vimjam and Al Joseph, "Challenges in Verification of Clock Domain Crossings", DAC knowledge center Article
  3. Ping Yeung, "Five Steps to Quality CDC Verification", Mentor Graphics, Advanced Verification White Paper
  4. M. Litterick, "Full Flow Clock Domain Crossing – From Source to Si", DVCON 2016
  5. Anwesha Choudhury, Ashish Hari, "Accelerating CDC Verification Closure on Gate-Level Designs", DVCON 2017

Back to Top

Table of Contents

Verification Horizons Articles:

  • What Does Improving Your Golf Swing Have in Common with Verification?

  • Parallel Debug: A Path to a Better Big Data Diaspora

  • Portable Stimulus Modeling in a High-Level Synthesis User's Verification Flow

  • Smoothing the Path to Software-Driven Verification with Portable Stimulus

  • Verification Planning with Questa® Verification Management

  • MIPI® CSI2 TX IP Verification Using Questa® VIPs

  • Converting Legacy USB IP to a Low Power USB IP

  • Understanding the UPF Power Domain and Domain Boundary

  • Automation and Reuse in RISC-V Verification Flow

  • Emulation – A Job Management Strategy to Maximize Use

  • RTL CDC Is No Longer Enough — How Gate-Level CDC Is Now Essential to First Pass Success

  • Formal Verification: Not Just for Control Paths

Siemens Digital Industries Software

Siemens Digital Industries Software

##TodayMeetsTomorrow

Solutions

  • Cloud
  • Mendix
  • Siemens EDA
  • MindSphere
  • Siemens PLM
  • View all portfolio

Explore

  • Digital Journeys
  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Newsletter
  • Customer Stories

Contact Us

USA:

phone-office +1 800 547 3000

See our Worldwide Directory

  • Contact Us
  • Support Center
  • Give us Feedback
©2021 Siemens Digital Industries Software. All Rights Reserved.
Terms of Use Privacy Cookie Policy