Automating Reset Domain Crossing (RDC) Verification with Advanced Data Analytics

The complexity of System-on-Chip (SoC) designs continues to rise at an accelerated rate, with design complexity doubling approximately every two years. This increasing complexity makes verification a more difficult and time-consuming task for design engineers. Among the key verification challenges is managing reset domain crossing (RDC) issues, particularly in designs that utilize multiple asynchronous resets. RDC occurs when data is transferred between different reset domains.

While the use of Electronic Design Automation (EDA) tools for clock domain crossing (CDC) verification has become a common practice, the verification of RDCs—an equally important aspect—has only recently gained prominence. RDC verification is necessary to ensure data stability between asynchronous reset domains. Failure to do so can hide timing and metastability issues in a SoC, resulting in unpredictable behavior during its operation.

Siemens EDA recently published a whitepaper addressing this important topic and how advanced data analytics techniques can be leveraged to achieve design verification of RDCs.

Challenges of RDC Verification

RDC verification tools are essential for detecting potential metastability issues in designs, but they generate vast amounts of data—often millions of RDC paths. Engineers must manually analyze this data to find common root causes for violations and apply appropriate constraints. This process is both time-consuming and error-prone, often leading to multiple design iterations that delay project timelines.

One of the primary challenges is the sheer volume of RDC violations reported, especially in the early stages of design when no constraints have been applied. The lack of proper constraints related to reset ordering, reset grouping, and isolation signals can lead to false violations and unnecessary debugging effort. Design teams can spend weeks analyzing these violations manually, often overlooking critical issues or spending too much time on trivial paths.

Addressing RDC Challenges with Data Analytics

The manual approach to RDC verification is no longer sufficient given the complexity of modern SoC designs. Advanced data analytics and supervised data processing techniques offer a promising solution. These techniques can quickly analyze the vast amounts of data generated by RDC tools, identify patterns, and suggest optimal setup constraints. By recognizing common root causes of violations, such as incorrect reset domain grouping or reset ordering issues, data analytics techniques provide recommendations for constraints that can be applied to resolve multiple RDC paths at once. These constraints may include stable signal declarations, reset ordering specifications, reset domains, isolation signals, and constant declarations.

Figure 1. RDC verification using data analysis techniques.

Key Recommendations for Improving RDC Verification

Several specific recommendations are identified in the whitepaper, to reduce RDC violations through automated data analysis.

Reset Ordering: Ensuring that the receiver flop’s reset is asserted before the transmitter flop’s reset can prevent metastability. If proper ordering constraints are not defined, RDC tools may flag multiple violations due to this common issue. For example, if reset RST2 (receiver) is asserted before RST1 (transmitter), it ensures that metastability does not propagate downstream.

Synchronous Reset Domains: RDC issues arise when reset signals for the source and destination registers are asynchronous. Grouping resets into synchronous reset domains during setup reduces the number of reported crossings.

Directive Specifications: Defining valid constraints for specific design scenarios can prevent unnecessary RDC violations. For example, if a receiving register’s clock is off when a transmitter register’s reset is asserted, there is no risk of metastability, and the tool should not report a violation. Neglecting such constraints leads to noisy results.

Stable Signals: Some signals within the design may not contribute to metastability despite being part of asynchronous reset domains. If these are not marked as stable, they will be incorrectly flagged as potential violations.

Isolation Signals: Isolation techniques can prevent metastability by isolating data transfer between reset domains during asynchronous reset assertion. Properly specified isolation constraints reduce the number of RDC paths requiring manual review.

Non-Resettable Receiver Registers: In some cases, non-resettable registers (NRR) may not pose a metastability risk if a downstream register in the same reset domain exists. Failing to specify such conditions leads to false violations.

Case Study: Data Analytics in Action

A case study was conducted to evaluate the effectiveness of using data analytics in RDC verification. The design in question consisted of 263,657 register bits, multiple clock domains, and nine reset domains. Initial RDC verification runs with manually applied constraints identified approximately 8,000 RDC paths.

After applying advanced data analytics techniques, a consolidated report was generated, recommending several constraints. These constraints addressed reset ordering, data isolation, and synchronous reset domain grouping, among other issues. Following the application of these recommendations, the number of RDC violations dropped from 8,000 to 2,732—a more than 60% reduction in violations.

The use of a threshold value of 200 (indicating constraints would be recommended only if they impacted at least 200 paths) helped streamline the process, focusing on high-impact issues and minimizing noise. The time to reach RDC verification closure was reduced from ten days to under four days, showcasing the significant time savings from data-driven analysis.

Results and Impact

The case study demonstrated that the application of data analytics to RDC verification can lead to a significant reduction in unsynchronized crossings and violations. By systematically identifying root causes and applying targeted constraints, verification engineers were able to resolve up to 60% of RDC violations without manual intervention. This reduction in violations accelerated the verification closure process and improved overall design quality. Additionally, the flexibility provided by the analytics approach—allowing engineers to focus on high-impact suggestions—streamlined the debugging process and ensured that effort was invested in solving critical design issues.

The table below shows the results from applying data analytics techniques to RDC verification of five different designs.

Summary

As SoC designs grow in complexity, traditional manual RDC verification methods are not scalable. By incorporating advanced data analytics into the verification process, engineers can significantly reduce closure time, improve result quality, and avoid costly silicon respins. These techniques not only accelerate root cause identification but also provide actionable insights through constraint recommendations that target common design issues. This automated approach ensures that real design bugs are addressed early, reducing metastability risks and strengthening the final SoC design. Integrating these methods into existing verification flows promises to save time and effort while delivering higher-quality, error-free designs.

The entire whitepaper can be downloaded from here.