Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Reset Domain Crossing Errors Can Break Your ASIC!
In the recent blog post on the challenges of clock domain crossing (CDC), we asserted that CDC errors can break your ASIC. Reset domain crossing (RDC) errors can be equally catastrophic, so in Part 2 we will discuss what the RDC challenges facing IP integrators are.
Turns out you need robust signoff for CDC AND RDC!
Historically, resets were confined to externally generated power-on (POR) or warm resets, where the entire ASIC design is reset to a known start state. Nowadays, large ASICs can contain hundreds of separate resets. These are generated internally under the control of software (or hardware), for the purposes of power management, debug, or for error-recovery mechanisms such as those required for safety-critical systems, for example.
As with clock gating, reset mechanisms have a functional behavior that must be functionally verified. This is a traditional verification, or system validation, problem that can be solved with traditional verification strategies, both dynamic and static. Metastability induced from asynchronous resets is another class of design flaw that can lead to a total chip failure, with all the associated costs of re-spinning a modern multi-billion gate ASIC! It¡¯s a class of problem that you can rarely work around in software. This risk is exacerbated by the ever-increasing complexity of resets. A portion of the chip with a unique reset signal is called a reset domain, and a signal traveling from one reset domain to another creates an RDC. RDCs can be susceptible to metastability, and this can even occur within a single clock domain as illustrated below.
RDC errors naturally occur at a much lower rate than CDC errors. Think about clocks running continuously, versus how often reset events occur. This can make RDC errors difficult to identify, debug and root-cause in final silicon and is another good reason why RDC analysis is a critical pre-silicon signoff criterion.
ASIC developers need verification strategies to eliminate this class of problems at the pre-silicon phase. To achieve RDC signoff, developers should embed RDC verification strategies into their full ASIC development workflow, so that RDC analysis can be performed at the earliest stages of RTL development, leading to a smooth, ¡°no surprises¡± RDC signoff before final tape-out release.
So, what are the key RDC challenges those developers need to be aware of?
Dealing with Reset-less Sequential Paths
A unique challenge for resets arises from the sequential nature of resets where there can be many reset-less elements in a data path pipeline as shown below.
So, while the basic problem is the same as CDC (inputs to flops change asynchronously to the clock and may violate input setup and hold times, leading to metastability), RDC is a fundamentally different problem that requires RDC engines to perform a different analysis from CDC engines. RDC metastability can propagate down these pipelines until the next reset-able element is encountered. This means that RDC paths can span long chains of sequential logic and any RDC analysis methodology will need to be able to detect these reset-less structures by performing a global analysis across the design.
When designers recognize potential RDC paths in their designs, they can protect these paths with qualifier signals and blocking gates, and there are multiple strategies on where to place these blocking gates in the sequential path. Alternatively, designers can block clocks when resets are asserted or ensure that the final flop is from the same reset domain. RDC analysis tools need to be able to identify these functional mitigation features and eliminate all false negatives arising from RDC path analysis.
VC SpyGlass? RDC solves this problem as the analysis engines can identify RDC paths in the design across different depths of reset-less pipelines and can identify commonly used mitigation functionality in the design to minimize the reporting of false negatives that would otherwise increase the manual analysis required for RDC signoff.
RDC on Clock Paths
RDC paths can propagate directly into clocks if the output from the reset flop propagates into clock gating cell inputs. In other words, metastability originating from an asynchronous reset causes clock signals to glitch, with unpredictable results.
Take Care with RDC Setup
Like CDC verification, successful RDC verification is dependent on the user setup. You must input the correct constraints and identify the correct waivers. Mistakes here can lead to false fails (false negatives) or, worse, missed fails (false positives). Synopsys PrimeTime? compatible SDC is natively supported in VC SpyGlass RDC to capture clock & IO intent, while advanced reset/RDC related constraints are additionally captured in TCL.
Further, RDC analysis needs to understand and recognize when retention flops or isolation cells are going to be inserted between reset domains or power domains by the synthesis or place-and-route tools. These inserted cells can affect RDC paths and must be accounted for. For this reason, VC SpyGlass RDC is tightly coupled with Synopsys VC LP? and consumes IEEE Standard UPF power intent files to enable power-aware RDC analysis.
Again, the White Noise Problem
The volume of violations that are output can be a challenge for manual analysis. Too much output can mean that there are too many false negatives that need to be analyzed and waived, and this increases the risk that a true negative will be missed. Some assistance from the tool is required to reduce this analysis burden and reduce the risk of overlooked true negatives. VC SpyGlass RDC uses smart grouping of output violations with multiple levels of grouping based on various fields like source/destination resets, clocks, or flops to reduce this manual analysis burden for the engineer.
Scalability, Performance, and Debug Productivity
As with VC SpyGlass? CDC and the other static verification solutions that form the Synopsys Verification Continuum? platform, VC SpyGlass RDC solves the challenges of scalability, performance, and debug productivity necessary to handle modern multi-billion gate ASIC designs. This can be done using either a full-flat analysis or a hierarchical flow which uses signoff abstraction models (SAM) to allow a bottom-up approach, enabling RDC analysis to scale and perform well for the largest of designs. In fact, VC SpyGlass RDC beats previous generations of RDC solutions by about 3x on performance.
Finally, as we all know, engineering time is often the limiting factor over compute time and runtimes for many aspects of ASIC development workflows, so a familiar high productivity debug environment thanks to the integration of the leading Verdi debugger, is a welcome time-saver when it comes to RDC debug.
Continue Reading
Blog
4 min read
/
Oct 28, 2024
Hardware-Assisted Verification: Unlocking the Future of Chip and System Design
Blog
4 min read
/
Oct 21, 2024
Accelerating AI Chip Development and Reducing Risk with Pre-silicon, Secure, Cloud-based Emulation
Blog
2 min read
/
Sep 12, 2024
Industry First Verification IP for Arm AMBA DTI-G
