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

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

      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • Questa Static and Formal Apps
      • 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 2018
  • RTL Glitch Verification

RTL Glitch Verification

Verification Horizons - Tom Fitzpatrick, Editor

RTL Glitch Verification by Ajay Daga, Naveen Battu - FishTail Design Automation, Inc.

It is important that certain timing endpoints on a design are safe from glitches. For example, it is necessary that an asynchronous reset never have a glitch that momentarily resets a flop. It is also necessary that multi-cycle paths are safe from glitches, i.e., it should not be the case that while a cycle accurate simulation of the RTL shows correct multi-cycle behavior, once delays are accounted for a glitch can propagate along the path resulting in a single-cycle path.

Traditionally, engineers have verified that a design is safe from glitches with delay-annotated gate-level simulation. There are several issues with this approach – it only confirms that there is no glitch for specific delay values and it happens late in the design cycle, i.e., it is late and incomplete. What engineers want is to establish, once their RTL is frozen, that it is impossible for certain timing endpoints to glitch regardless of the final gate-level implementation and circuit delays. They want to make sure that they have ensured safety from glitches by design.

In this article we present an approach to establish that a design is glitch-safe using the same collateral that is provided as input to logic synthesis – RTL and SDC constraints – no other input is required by the flow. Where possible, formal techniques are used to establish that an endpoint is glitch safe. When formal techniques do not prove that an endpoint is glitch-safe, assertions are automatically generated and provided as input to RTL simulation. Engineers review simulation assertion failures and resolve issues by fixing their RTL. If an assertion fails then an endpoint is at risk of glitching and an RTL change is required. The benefit of this approach is that it is complete (assuming simulation coverage is reasonable), happens early in the design cycle (not close to tapeout) and there is no noise (bogus problems are not reviewed by designers). We present results from the application of this approach on real designs.

GLITCHES

Consider the simple two-input and gate shown in Figure 1. If, at the rising edge of a clock, A rises and B falls then the final value on the output Z stays low. A cycle-accurate simulation would show the value of Z remaining unchanged (it was low in the previous clock-cycle and stays low in the current clock-cycle). If, however, once circuit delays are accounted for, B falls after A rises then the output Z will momentarily glitch high.

Figure 1 - Glitch on an And-Gate:

An and-gate can create a glitch-high and an or-gate can similarly create a glitch-low. Further, an and-gate can propagate a glitch (either glitch-high or glitch-low) on one of its inputs, if its other inputs are high. Similarly, an or-gate can propagate a glitch on one of its inputs if its other inputs are low. In general, any multi-input gate (MIG) can, based on circuit delay, create a glitch and this glitch can then propagate forward through a design. In this article we focus on two situations where glitches can cause silicon failure:

  1. Glitches that momentarily assert asynchronous resets
  2. Glitches that invalidate multi-cycle path specifications

Glitches on Asynchronous Resets

Consider the circuit shown in Figure 2. The clrz pin is an asynchronous reset on a flop. When this pin is low the flop is reset. It is critical that the clrz pin never glitch-low – if it were to do so then the flop would momentarily reset and this would result in circuit failure. The clrz pin, however, is driven by multiple MIGs that could all create a glitch and so closer inspection is required to establish that the pin is safe from a glitch-low situation. The MIGs that are shaded green in the figure can never create a glitch of the required polarity and so they are not an issue. For example, the nand-gate U13 would need to glitch-high for a glitch-low to propagate to clrz and nand-gates can only create a glitch-low. So, U13 cannot cause an issue. The gates shown in red, however, could create a glitch of the appropriate polarity and this glitch could propagate to the clrz pin.

Figure 2 - Glitches on Asynchronous Resets:

For example, as shown in Figure 3, U246/Z will glitch low if POK10_1P8 is low and if the falling transition on POK10_OUT_1P8 happens after the rising transition on POKEN10_1P8. This glitch will then propagate through to U243/Z if the other side-inputs to this gate are both high, through U33/Z if the other side-input to this gate is low, through U13/Z if the other side-input of this gate is high, eventually causing the clrz pin to glitch low. For this circuit to be safe from silicon failure the situation just described must never happen.

Figure 3 - Waveform Showing Glitch Creation and Propagation to an Asynchronous Reset:

Glitches on Multi-Cycle Paths

Consider the circuit shown in Figure 4 where an engineer has specified a two-cycle hold multi-cycle path (MCP) through data. This MCP specification requires that data not transition immediately after the rising edge of cclk – instead any transition on data must happen a clock cycle after cclk rises. The data net is driven by an or-gate and a cycle accurate simulation, shown in Figure 5, shows that the output of the or-gate stays stable for a clock-cycle after cclk rises. However, at the time that cclk rises both the flops (start_input_write and write_inflight) that drive the or-gate transition. If the write_inflight falling transition happens after the start_input_write rising transition then data will glitch, as shown in Figure 6, and this glitch invalidates the single-cycle MCP specification (data does not, after all, stay stable for a clock-cycle after the cclk rises). As STA will time the path with the MCP specification in place this glitch could easily cause a silicon issue.

Figure 4 - Glitch on Multi-Cycle Path:


Figure 5 - Cycle Accurate Simulation Shows No Glitch:


Figure 6 - Delay-Annotated Simulation Shows Glitch:

DELAY ANNOTATED GATE-LEVEL SIMULATION CANNOT RELIABLY CATCH GLITCH ISSUES

Engineers address the issue of glitches by relying on delay-annotated gate-level simulation. There are several issues with this approach. Gate-level simulation happens late in the design cycle, close to tape-out. That is far too late to be catching an issue whose fix almost always requires an RTL change. It is also well acknowledged that given the long runtimes of gate-level simulation, regression coverage is much worse as compared to RTL simulation. So, it is easily possible that the simulation vector required to create a glitch and have it propagate to the endpoint is not covered by gate-level simulation. Finally, the most fundamental flaw with gate-level simulation is that it is testing a circuit under a specific delay assignment (minimum, nominal, or maximum). However, circuit delays vary within the minimum/maximum range and it is trivially possible for gate-level simulation to not see a glitch because it did not simulate the range of possible delay values, just specific values within this range. For example, consider that the delays for the transitions at the input of the and-gate in Figure 1 are such that A has delays of (2:4:6) for (min:typ:max) and B has delays of (1:3:5). If the design is simulated at min, typ and max corners B always falls before A rises and no glitch is generated at the output of the and-gate. However, it is possible for the delay on B to be 4, while the delay on A is 2 (these delay assignments are within the specified range of delays for A and B) and the output of the and-gate could glitch.

Simulating a design at specific delay values to catch glitches is seriously flawed. A small perturbation in the implementation can easily change the delay characteristics of a design resulting in a glitch. It’s not realistic to repeatedly run gate-level simulation every time there is a small change in place and route. Fundamentally, there is no guarantee that a glitch issue will be caught by gate-level simulations because of how incomplete this approach is and even if the issue is caught it is painful to make RTL changes when a project is close to tapeout.

FishTail’s Glitch Verification Methodology

FishTail’s approach to glitch verification is focused on answering the following question: is my design safe from glitches regardless of the final gate-level implementation and its circuit delays, i.e., as long my gate-level netlist is logically equivalent to the RTL can I, at the RTL, establish that the design is safe from glitches and not revisit this analysis as implementation progresses.

The FishTail glitch verification flow, shown in Figure 7, takes as input synthesizable RTL and the SDC constraints for a design – the same collateral that is provided as input to logic synthesis. The tool identifies all the timing endpoints on the design that need to be glitch-safe. These are the asynchronous resets on flops and any timing exceptions (false and multi-cycle paths) whose endpoints need to be checked for glitches. A user can manually add to the list of endpoints that will be checked for glitches. For each endpoint the tool establishes whether a glitch of a certain polarity is not permitted (asynchronous resets for example should not glitch at the reset assertion level) or whether both glitch-low and glitch-high are not permitted (endpoints associated with timing exceptions).

Figure 7 - FishTail Glitch Verification Flow:

For each timing endpoint that needs to be glitch safe the tool establishes all the MIGs that drive this endpoint. For the circuits in Figures 2 and 4, the MIGs are shown in either red or green. At each MIG the tool establishes whether a glitch of the desired polarity can be generated. Depending on the cell-type some MIGs cannot create a glitch of the desired polarity. Nothing more needs to be done with these MIGs. For the MIGs for which a glitch can be created the tool establishes if the condition required to propagate the glitch to the endpoint can ever be satisfied. This is done by formally computing the Boolean condition for a transition on the MIG output to propagate to the endpoint. If the propagation condition evaluates to 0, then the glitch cannot propagate.

After weeding out the MIGs that cannot create a glitch of the required polarity (the ones shown in green in Figure 2) and those that are unable to propagate the glitch to the endpoint the tool is left with MIGs that could potentially cause a silicon issue depending on the sequential behavior of the design. Whether or not there is an issue is a function of the cone of logic that drives the MIG and whether this logic can cause the appropriate transitions at the input of the MIG and then allow these transitions to propagate to the endpoint. Formal closure of the verification process for such MIGs typically requires an engineer to provide additional input to the tool that constrains how the logic cones are driven. Providing such input takes time, requires the RTL owner to review formal verification results and is a painful, cumbersome and error-prone process. Typically, this is where any momentum established from using a tool comes to a grinding halt.

FishTail’s glitch verification methodology, on the other hand, does not require any additional input from an engineer, nor does it require an RTL designer to spend time reviewing formal failures, constraining the formal tool, etc. For any MIG that does not pass formal proof the tool generates an assertion that states the property that must hold for the MIG to not cause a glitch at the endpoint. This is a functional property that the design must satisfy to be safe from glitches for any and all delay values. An example assertion, for U246/Z in Figure 2, is shown below in Figure 8.

Figure 8 - Example Assertion Generated to Test Glitch Safety:

The FishTail formal tool does not synthesize RTL to gates – it does not perform its formal analysis on the synthesized gate-level representation of the design. Instead, formal verification is performed at the RTL level and so the assertions generated by the tool refer to RTL nets. This allows compact assertions to be generated that are easily integrated into an RTL simulator – the tool is working on the same model of the design as a simulator. Bind statements accompany the assertion so that integrating the assertions into an RTL simulation environment simply requires compiling the assertion file generated by FishTail along with the rest of the RTL for the design. No delay information is required when performing RTL simulation with FishTail generated assertions to verify if a design is glitch-safe. A cycle accurate simulation is sufficient. The assertions test whether it is possible for a glitch to be generated (highlighted in yellow in Figure 8), and then for the glitch to propagate to the endpoint (highlighted in blue in Figure 8). If both are possible then the assertion fails and an engineer reviews the failing assertion using debug strategies that he is already familiar with. If the assertions pass and the testbench coverage for the design is reasonable then the engineers can be confident that their design is safe from glitches regardless of how the RTL is implemented. The impact of synthesis transformations (on mux structures for example) is automatically handled by the tool so that there is no need to revisit this verification on the synthesized netlist.

Summary

Glitches that propagate to points on the design where they should not can cause silicon failure. Identifying that a design is safe from such glitches is an essential aspect of pre-silicon validation. The dominant approach to glitch verification in the industry today relies on gate-level simulation. This approach is woefully inadequate because it happens late in the design flow, gate-level simulation coverage is poor and simulating the design with specific delay values in the hope that it will throw up a glitch is naïve. FishTail’s solution to the problem requires an input collateral that is readily available (RTL and SDC) and establishes if a design is safe from glitches for any and all circuit delay. Most importantly, this approach leverages RTL simulation, so that RTL designers are not required to constrain a formal tool, or learn the debug environment that accompanies a formal tool. Instead, they simply review simulation assertion failures using techniques they are already familiar with.

Back to Top

Table of Contents

Verification Horizons Articles:

  • A College Championship, Our NBA Finals Expectations, and Dreaded Feature Creep

  • Comprehensive CDC Verification with Advanced Hierarchical Data Models

  • Creating SoC Integration Tests with Portable Stimulus and UVM Register Models

  • It’s Not My Fault! How to Run a Better Fault Campaign Using Formal

  • Coverage Driven Verification of NVMe Using Questa® VIP (QVIP)

  • Part 2: Power Aware Static Verification – From Power Intent to Microarchitectural Checks of Low-Power Designs

  • Three Main Components to Look for in Your Emulation Platform

  • Complex Addressable Registers in Mission Critical Applications

  • RTL Glitch Verification

  • UVM-based Verification of a RISC-V Processor Core Using a Golden Predictor Model and a Configuration Layer

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