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

      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • UVM Framework
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • 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 - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

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

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home /
  • Verification Horizons /
  • December 2019 /
  • Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon

Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon

Verification Horizons - Tom Fitzpatrick, Editor

Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon Abdelouahab Ayari, Sukriti Bisht, Sulabh Kumar Khare, Ashish Hari, and Kurt Takara - Mentor, A Siemens Business

INTRODUCTION

Today’s complex designs include multiple asynchronous clocks and the signals crossing between asynchronous clock-domains may result in functional errors. When a signal from one asynchronous clock-domain is sampled by a register on a different asynchronous clock-domain, the setup/hold timing requirement will be violated for the destination register. The setup/hold timing violation indicates that the destination register may become metastable and that the destination register will settle to an unpredictable value and possibly cause a functional error. Although clock-domain crossing (CDC) verification is a critical task in design verification projects, many design teams only statically verify CDC synchronization structures.

When designers add synchronization logic to prevent the propagation of metastable events, designers should implement and verify the correct CDC protocol. Without a correctly implemented protocol, a CDC structure will not function correctly and thus, lose or corrupt data or propagate metastability. It is common practice for CDC tools to generate assertions to check correct protocol adherence, but assertion generation is not sufficient for designers to verify CDC protocols.

In this article, we will discuss the difficulties encountered with traditional CDC protocol verification methodologies and present a complete methodology to overcome the current challenges. Following are the key challenges:

  • Significant effort and time is required to setup the design and assertions for formal and simulation
  • Lack of integration between structural analysis, formal verification, and simulation steps
  • Considerable effort required to review and debug firings in formal and simulation

The proposed methodology improves ease of setup by automating the setup, constraints, and results analysis from static CDC analysis to Formal to Simulation. The automation provided by this methodology avoids manual scripting efforts and thus reduces setup effort and setup errors. The methodology also improves debug productivity by addressing the important issue of correlating structural analysis, formal verification and
simulation results.

WHAT ARE CDC PROTOCOLS And WHY ARE THEY NEEDED?

Although CDC synchronization structures are required to prevent metastability on CDC paths, designer may overlook the fact that a good structure alone is not sufficient to avoid CDC errors. If a CDC synchronizer is not used correctly, the CDC path may experience data loss or data corruption or in the worst case, metastability. The rules that define the correct usage of a CDC synchronizer are called CDC protocols.

In the simplest protocol case, a 2DFF synchronizer requires a stability protocol where the TX data must be held stable for at least 2 RX clock cycles in order for the RX register to reliably capture the TX data and prevent data loss or data corruption. In a more complex protocol case, a data-mux (DMUX) synchronizer requires that the TX data must be stable when the mux enable is active and allowing the RX register to sample the TX data. If the DMUX synchronizer protocol is violated, the RX register will become metastable even though a correct DMUX structure was implemented.

CDC protocol errors must be identified and addressed early in the design cycle, otherwise they can lead to functional failures in later stages. These functional failures can further result in increased iterations and even silicon re-spins. To ensure such issues are not missed, designers and verification engineers verify synchronizer protocols by generating assertions for synchronizer protocols and verifying them using formal model checking and simulation techniques.

CDC PROTOCOL VERIFICATION CHALLENGES

Protocol verification is critical for avoiding CDC errors, but often, project teams do not utilize protocol verification due to the multitude of deployment challenges. The common challenges for deployment include protocol verification setup, constraints setup, and the difficulty in reviewing and debugging protocol results.

Protocol Assertion Generation and Verification Setup

CDC structural analysis identifies the CDC synchronization structures, then CDC utilities will automatically generate protocol assertions for the CDC synchronization structures. The CDC utilities generate assertion instantiations that connect the TX register, RX register, TX clock, RX clock, TX reset, and RX reset to the appropriate protocol assertion.

After CDC protocol assertions are generated, it can be difficult for designers to incorporate these assertions into formal verification and simulation environments. The compilation, formal analysis and simulation commands or scripts are required for running simulation and formal analysis. The clock frequency information from SDC and CDC constraints are used to specify the stability protocol requirement for CDC synchronizer structures.

SystemVerilog assertion and SystemVerilog bind files must be added to the formal and simulation environments. For designers unfamiliar with formal analysis, it is challenging to generate formal compilation and analysis run scripts. For complex simulation environments, it is challenging to incorporate the protocol assertions into simulation regressions.

Formal Constraints Generation

The formal environment requires designers to specify formal setup constraints that include design configuration information, clock information, and input port information. The formal design configuration information includes constants specified for configuration ports and registers. The formal clock information includes the specification of the design clocks and the clock frequencies. The formal port information includes the specification of the primary input ports and their related clock- domain information.

CDC Protocol Assertion Debug

In traditional CDC protocol methods, the protocol verification review and debug is isolated from the CDC structural analysis. It is difficult for designers to correlate protocol assertion violations in the simulation or formal environment to the associated CDC synchronization structure. This lack of correlation between structural and protocol verification causes more time and effort spent by designers for review and debug of protocol verification results.

PROPOSED CDC PROTOCOL METHODOLOGY

In this article, we propose a methodology that not only helps overcome the common challenges of traditional protocol verification methods, but also better leverages formal model checking and simulation technologies to improve protocol verification results. Figure 1 below illustrates the proposed methodology.

Figure 1 - Protocol Verification Flow


The proposed methodology has the following workflow:

  1. Static CDC Analysis: Perform static CDC analysis on the design to ensure that all the relevant CDC paths are synchronized using proper synchronizers. In addition, automatically generate protocol assertions, generate formal verification constraints, generate formal verification and simulation setups:
    • Automatic Protocol Assertion Generation: Generate assertions for protocols of each synchronizer in the design. Based on static CDC analysis, the CDC protocol generation utility generates protocol assertions for each CDC synchronizer. The protocol assertions are generated depending upon the type of synchronizer and its connections (Figure 2).

    Figure 2: CDC Protocol Assertion Instantiation

    assert_cdc_sync #(2, 1,1) two_diff_81824 (
    	            .tx_data(demo_top.pass_en[0]),
    	            .tx_clock(demo_top.cpu_clk_in),
    	            .rx_clock(demo_top.mac_clk_in),
    	            .tx_reset(1'b0),
    	            .rx_reset(1'b0),
    	            .areset(w_2));
    • Automatic Formal Verification Constraints Generation: Generate formal model checking constraints from CDC analysis. The CDC protocol generation utility converts the CDC information for constant, stable, gray-code signals into SVA assumptions for formal verification. In addition, input and output port clock-domain information will also be converted into formal constraints to improve the accuracy of formal counter-examples.
    • Automatic Formal Verification and Simulation Setup: Generate setup and scripts for running formal verification and simulation. The CDC protocol generation utility will generate formal model checking run scripts. The utility will also generate a simulation argument file to be added to designer’s existing simulation environment, so designers can easily add protocol assertions and can avoid manually adding multiple assertion and bind module files to their simulation.
  2. Formal Analysis: Run formal model checking to verify the auto-generated synchronizer protocol assertions using the generated formal verification setup and script. The CDC protocol generation utility generates the formal compile and run scripts. The automated formal setup significantly reduces the effort required to setup the design for formal analysis and also avoids the debug effort to resolve incomplete or incorrect setup issues. In order to run formal analysis, designers simply execute the makefile (i.e. “make all”).
  3. Simulation: Run simulation by adding the auto-generated setup to the existing simulation environment to verify the non-proven protocol assertions. The CDC protocol generation utility generates simulation argument files for compilation and simulation.
    During the formal analysis, the formal analysis script automatically updates the simulation setup to remove the proven assertions from the list of assertions for simulation. If formal analysis is run without formal design constraints, a formal proof for any protocol assertion indicates that the protocol can never be violated for the associated CDC synchronization structure. This proof indicates that the synchronization structure is safe from data loss, data corruption and the propagation of metastability. Removing the proven assertions from simulation will reduce the simulation runtime and reduce the designer effort for reviewing simulation results for proven assertions that cannot be violated in simulation.
  4. Review and Debug CDC Protocol Results: Review the aggregated structural CDC analysis, formal verification, and simulation results. The correlation between the multiple technologies (static CDC analysis, formal model checking, simulation) enables designers to more quickly and easily debug and resolve protocol errors. This correlation enables designers to find the CDC structure associated with a protocol failure, then quickly diagnose the cause of the protocol error. This improved review and debug ensures that bugs are correctly analyzed and protocol errors for CDC synchronizers are not missed or incorrectly analyzed.

REAL WORLD RESULTS

This CDC protocol verification methodology was applied on a few real world designs. The deployment of the methodology on real life designs provided evidence that this methodology significantly reduced design and verification engineers’ effort and helped to achieve faster design closure.

Using a traditional protocol verification methodology, the protocol assertions were validated first in a formal verification environment. The design settings and constraints like clocks, resets, constants, and input port constraints were manually translated from the static CDC environment and re-specified as formal constraints. This constraints translation required significant manual effort and formal expertise. Once the formal tool environment setup was complete, the design was verified formally and the assertion firing counter-examples were debugged.

Similarly, in the proposed methodology, the first step was protocol assertion verification in formal verification environment. The design configurations and constraints for formal analysis were auto-generated by using the proposed methodology. This auto-generated setup was reviewed and used to run formal analysis on the design and assertions. The setup automation avoided the need for manual setup effort and formal expertise that would be required by a traditional approach to port the setup from CDC to formal.

Formal verification results included proofs, firings, and inconclusives for CDC protocol assertions. The auto-generated formal setup did not include design constraints, so the firings produced unconstrained formal assertion violations that are in most cases, counter-examples with illegal stimulus sets. For designers without formal model checking expertise, it is difficult to debug and/or resolve fired and inconclusive assertions, so instead of debugging these difficult cases, designers will promote these assertions to simulation. With the traditional methodologies, proven protocol assertions are re-verified in a simulation environment or must be manually removed from the simulation setup.

In the proposed methodology, only non-proven assertions from formal analysis are verified in simulation. The proven assertions are automatically removed from the simulation setup. The auto-generated simulation arguments file is added to the existing simulation environment. Any simulation assertion firings indicate a violation of the CDC synchronizer protocol that would result in data loss, data corruption or metastability propagation on the associated CDC path. Designers must debug simulation firings and fix the CDC logic to adhere to the synchronizer protocol rules. Significant reduction in debug effort and time was observed due to running simulation only for formal non-proven assertions.

Tables 1 and 2 summarizes the comparison between the traditional and proposed methodology performed on a set of real life designs, ranging from 1 to 30 million gates.

The following improvements resulted:

  • Significant reduction in formal setup time. The setup time was reduced due to the automated setup generation. In addition to the reduction in setup time, the setup debug effort was reduced by avoiding the incremental debug iterations of incomplete and incorrect setups. The setup time was reduced by 3x-5x.
  • Reduction in setup time for simulation. The setup time was reduced due to the automated setup generation. In addition to the reduction in setup time, the setup debug effort was reduced by avoiding the incremental debug iterations of incomplete and incorrect setups. For design C, the setup time was reduced by 6x-17x.
  • Reduction in false firings in formal analysis. The automated setup generation and the import of CDC design constraints into formal analysis reduced the formal setup errors and caused a reduction in false firings. The formal assertion firings were reduced by 59%-68%.
  • Increased formal coverage. The improved formal setup and constraints resulted in less inconclusive assertions and more proofs and firings.
  • Increased simulation coverage. Removing proven assertions from simulation resulted in a higher percentage of fired and covered simulation assertions. Since the proven assertion were not simulated in the proposed methodology, the proven assertions were considered covered in order to maintain simulation coverage consistency between the traditional and proposed methodologies.
  • Reduction in simulation verification time and effort. There was a reduction in the number of assertions passed to simulation due to exclusion of formally proven assertions thereby reducing the verification effort required for reviewing proven assertions in simulation. The correlation of structural CDC analysis, formal verification, and simulation results improved debug productivity and led to easier association of protocol errors with their associated CDC paths. The time and effort for reviewing and debugging simulation results was not measured for these design case studies.
  • Reduction in effort for debugging false simulation firings. In the proposed methodology, there was a reduction in the number of simulation assertion failures. In the proposed methodology, the CDC constraints used in formal analysis allowed more assertion proofs for cases where stable or gray-coding constraints enabled assertion proofs. These proven constraints were not run in simulation, so the designers would avoid debugging false simulation assertion firings. The time and effort for debugging false simulation firings was not measured for these design cases.

Table 1 - Results using traditional protocol verification methodology:

Table 2 - Results using proposed protocol verification methodology:


From the real life designs, the following were unaffected:

  • Minimal change in simulation runtime. The reduction in the number of assertions run in simulation due to exclusion of formally proven assertions did not significantly change the simulation runtime.

CONCLUSION

The proposed CDC protocol verification methodology described in this article is a systematic and repeatable solution for the design and verification of CDC synchronizer protocols. The automated setup process reduces the setup errors and the debug iterations required to resolve setup issues. Automated conversion of CDC constraints into formal model checking constraints improves the accuracy of formal analysis and reduces false formal firings. Finally, the integrated CDC structural analysis, formal verification and simulation results enables an easier to use debug environment that allows designers to debug and fix protocol errors more quickly and with less effort.

REFERENCES

[1] Mark Litterick, “Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using System Verilog Assertions”, Verilab
[2] William K. Lam, “Hardware Design Verification: Simulation and Formal Method-Based Approaches”, Prentice Hall, Mar 3, 2005
[3] Sulabh K. Khare, Ashish Hari, “Systematic Speedup Techniques for Functional CDC Verification Closure”, Mentor Graphics, advanced verification white paper
[4] Ping Yeung, “Five Steps to Quality CDC Verification,” Mentor Graphics, advanced verification white paper

Back to Top

Table of Contents

Verification Horizons Articles:

  • Lessons from “Verifying” the Harry Potter Franchise

  • Why Hardware Emulation Is Necessary to Verify Deep Learning Designs

  • Deadlock Prevention Made Easy with Formal Verification

  • Exercising State Machines with Command Sequences

  • Designing A Portable Stimulus Reuse Strategy

  • Don’t Forget the Protocol! A CDC Protocol Methodology to Avoid Bugs in Silicon

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock