Automotive SoCs Need Reset Domain Crossing Checks

When the number of clock domain crossings (CDCs) in SoCs proliferated it readily became apparent that traditional verification methods were not well suited to ensuring that they were properly handled in the design. This led to the creation of new methods and tools to check for correct interfaces between domains. Now, in automotive designs a similar issue is arising. Due to functional safety requirements, such as ISO 26262, automotive ICs need to be able to recover from faults and failures while continuing operation. This has led to the use of reset domains, which can be reset selectively as necessary while the surrounding blocks or the top level continue operation.

There are a number of cases where Reset Domain Crossings (RDCs) can be problematic and lead to functional issues. Siemens EDA in conjunction with NXP has a white paper titled “Systematic Methodology to Solve Reset Challenges in Automotive SOCs” that focuses the topic of finding and fixing issues with RDCs. It’s worth mentioning that Siemens EDA is the new name for Mentor.

The white paper starts out by describing the problem generally and discussing the prominent techniques used to ensure proper behavior. The first is reset sequencing, where the receiver’s flop is reset before the asynchronous reset in the transmitter’s domain. The second technique is to use isolation on the data or clock of the receiver’s flop prior to the occurrence of a reset in the transmitter’s domain. This can be done with a reset-gating signal that isolates either the data or clock.

Yet, the real challenge is to find where there are specific issues that can cause problems. The second part of the white paper covers several examples that cause reset domain crossing issues. Specifically, in automotive designs the authors cite some common real-world problems that can occur.

In many designs there are configuration registers that need to hold values during warm resets. The registers are loaded at power on reset (POR), but if a warm reset occurs simultaneously with POR, the values in the POR registers can become corrupted. Another case they mention is where a clock gating signal can glitch due to a reset on the controlling flop. If this happens to a flop in another reset domain that is active, it can cause failures. They also include several examples where there is combinational logic on the reset path. There are legitimate reasons for wanting this, but it complicates RDCs.

The authors outline a methodology that employs Siemens EDA’s Questa to formally, and exhaustively, verify RDCs. Designers identify the primary reset signals to help the tool better understand the reset structure of the design. Then the RDC tool generates a digital model of the reset structure, including locating local reset signals. Each reset is categorized according to its type. This model is elaborated with information such as reset polarity, reset source and output value of the sequential element upon reset.

This model allows structural checks that can reveal problems such as polarity usage mismatch or always asserted registers driving reset signals. Then there is a user aided step that involves grouping reset domains according to their asynchronous relationships and specifying information about reset sequencing.

The white paper closes with a summary of a case study. Here they explain how the tool classified each of the resets and identified inferred resets. Possible structural issues in RTL coding are identified at this point. Of the 90k RDCs the tool helped narrow down the list of potential issues to ~1.6% of those that needed a closer look. The outstanding issues were easily fixed using the methods presented in the white paper.

Questa RDC appears to offer a high value, low pain methodology for adding RDC checks to the verification process. Because it is built on the Questa platform it shares a common language front-end and uses the same formal based algorithms for its analysis. With the added reliability requirements of the automotive space, designers will probably be glad to have a tool like this to ensure that the now necessary reset domains are implemented properly. The full white paper is available for reading here.

Also Read:

Siemens EDA is Applying Machine Learning to Back-End Wafer Processing Simulation

CDC, Low Power Verification. Mentor and Cypress Perspective

Multicore System-on-Chip (SoC) – Now What?