On Analysis of RDC Issues for Identifying Reset Tree Design Bugs and Further Strategies for Noise Reduction

Static verification, including Clock-Domain Crossing (CDC) and Reset-Domain Crossing (RDC), is imperative to finding issues in complex SoCs. A decade ago, static verification technologies were a “nice to have.” Today, in an environment of ever-increasing design complexity, static verification is now so non-trivial that design and verification teams along with EDA vendors continue investigating newer checks and methodologies for static analysis.

The cost and schedule impact of design issues caught late in the design cycle have made engineers focus on RDC analysis of RTL designs. RDC analysis is challenging in a sense that it involves careful consideration of design reset strategies. Fixing RDC bugs properly often requires changing the reset architecture which can be very costly at late stage in the design cycle.

Additionally, a poorly architected reset strategy can lead to reset bugs escaping to silicon thereby leading to prejudicial wastage of thousands or even millions of dollars, design respins and project schedule slippage. It is often observed that engineers jump past analyzing RDC results without reviewing the setup checks. Setup check results must be analyzed. A RDC analysis run is initiated by compiling and elaborating the design thereby performing a detailed analysis of clock and reset trees. A good RDC analysis engine will do the analysis pessimistically so that it covers all the domain crossing signals and related issues, if any.

Pessimism in the analysis may lead to creation of new clock and reset-domains which can increase the noise in the results. Engineers can control the level of pessimism by using proper constraints. RDC analysis tools carve out analysis on clock and reset trees and provide a set of pointed/focused issues a designer can focus on before doing analysis on the actual domain crossing signals. There are many checks that need to be performed on the clock and reset trees, and this paper will discuss few such issues related to reset trees.

We have seen design engineers regularly use non-resettable registers (NRRs) in RTL designs. Resettable registers may be used on the periphery of the design while NRRs are generally used on internal paths. Using NRRs have many advantages, including reduced area and lower power consumption. Using non-resettable registers also comes with some challenges. We will highlight one such disadvantage of non-resettable register usage on reset paths.

RDC analysis results can be noisy because of the previously mentioned inherent pessimism in the analysis. RDC analysis methodologies need to provide a noise management strategy which requires minimal extra work for engineers. If noise management is not done properly it may lead to serious RDC issues being incorrectly masked, or not reported. We have investigated RDC analysis results on many designs and have found that often the analysis results are noisy because the analysis engine may not account for stable constraints applied on various signals on clock, and control paths. Using knowledge of system behavior and architecture, an engineer may apply constants and stables on certain signals; configuration registers are usually perfect examples of stable signals.

These registers usually don’t toggle during the functional operation of a chip and hence are not candidates for CDC/RDC analysis. It is expected that EDA tools consider these signals to be static and report paths associated with these signals as safe crossings. For RDC analysis we have observed that the tools report these “safe” paths as “unsafe” leading to noisy results.

This paper investigates how RDC tool should report such paths as safe RDC crossing. Engineers tend to use constraints (i.e. setting false paths) to eliminate paths from analysis completely, but this is no better than a waiver and can result in bugs. It is our recommendation that design rules should strictly disallow usage of such constraints. It is our belief that any RDC tool should automatically recognize functional false paths and report them. Functional false path reporting by the tool has many advantages. The first and foremost is that all the domain crossing paths are analyzed by the tool. EDA tools may apply formal verification technology to report these types of paths (even if unconstrained by the user). Doing so provides confidence that all the paths are analyzed.

Additionally, engineers can make necessary changes to the design at an early stage of design development to address domain crossing issues identified by the tools. The proposal we support in this paper is to analyze these paths under a different RDC scheme.