Four Steps To Resolving Reset Domain Crossing Data-Corruption In Automotive SoCs

By Kurt Takara (Siemens EDA), Ankush Sethi (NXP), and Aniruddha Gupta (NXP)

Modern automotive SoCs typically contain multiple asynchronous reset signals to ensure systematic functional recovery from unexpected situations and faults. This complex reset architecture leads to a new set of problems such as possible reset domain crossing (RDC) issues. Conventional clock domain crossing (CDC) verification methodologies cannot identify such critical bugs.

Complex automotive reset architectures need a dedicated verification solution to identify critical RDC bugs. If propagated to silicon, these bugs can lead to high-cost respins and a waste of precious engineering-hours. Further, these bugs cannot be captured through conventional STA or CDC design verification tools. A guided methodology to contain these type of bugs with minimal efforts is required.

To address this need, we developed a systematic flow to achieve clean automotive SoCs for RDC closure. This four-step methodology expedites the process of RDC verification using standard RDC verification tools and enables designers to meticulously tackle RDC issues.

Fig. 1: RDC verification methodology flowchart.

1. State known reset signals in the design

Designers should specify primary signals in the design which are intended to generate a reset pulse to put the system at some known state. Such reset signals can be called as user-specified reset signals during RDC analysis. This is a set up step that fine tunes the identification of synchronous and asynchronous reset sources using a verification tool. It helps to establish an optimistic co-relation between a localized reset source with a primary reset source, which in turn reduces the noise of results.

2. Reset tree structure verification

Structural verification of the reset architecture using an RDC verification tool creates a digital model of the reset architecture. This model identifies all localized and unspecified reset signals in the design based on RTL templates of coding synchronous and asynchronous resets. It represents a tree-like structure showing the relationships between various primary ports and localized reset sources. Similar to a clock tree, the root in the reset tree is the reference reset, and the branches are various localized reset sources. The resets are classified either as synchronous or asynchronous or as dual type, based on their usage in the RTL. Multiple properties of reset signals are also identified while transforming RTL code to reset tree such as:

• Polarity with which signals reset sequential elements (active high or active low)
• Source of the reset: primary input, derived combinational, generated by a reset synchronizer, driven by an un-synthesizable or un-driven net
• Output value of sequential element after being reset (set or reset signal)

The generation of a detailed reset tree enables structural checks on the reset architecture. Reset tree structure verification aids the designer to identify issues early in the design, before RDC analysis. Such errors are generally not caught by linter tools and need a dedicated solution to verify the reset tree structure. The designer can verify the correctness of the reset tree through these structural checks. These checks point to the reset source and show the path from the reset source to its usage flop in the form of a sub-circuit. Some of the issues with functional behavior, and usage of resets are:

• Polarity usage mismatch: An asynchronous reset source asserts a few functional flops during 1->0 transition and others at 0->1 transition. This implies a few functional registers would not get reset when the asynchronous reset is asserted. This can lead to errors in design functionality.
• Always asserted register: Reset pins of some flops are connected to signals such that they are always in the asserted state.

3. Map user intent to reset tree

This step involves identifying asynchronous relationships between various reset sources. The idea is that reset signals from a same source are asserted simultaneously and cannot lead to metastability in the design. In automotive SoC(s) we have global, hard resets, such as PoR, and deeper, more localized and specific resets. So the assertion of one reset leads to the assertion of other resets; however the vice versa may not always be true. For example, the assertion of hard resets leads to the immediate assertion of inner resets, while the reverse will never be true. To fine-tune the analysis, the designer should:

• Group reset domains according to their asynchronous relationships.
• Specify the information about reset sequencing (the order in which the assertion of one reset source affects the assertion of other reset source)

4. Reset domain verification

The final step is to analyze the RDC paths. The designer should verify if data paths crossing reset domains are metastability safe and employ any of the discussed mitigation strategies to contain RDC bugs.

Case in point: RDC verification of a complex automotive SoC

The proposed methodology was applied on a highly complex real automotive SoC with more than 1.7 million registers and 4 RAMs. A dedicated RDC verification tool was used for deploying the methodology. This tool was able to identify: asynchronous reset sources in the design, reset domains used by all the registers in the design, data path crossing reset domains, and asynchronous reset synchronizers. The diagram in Figure 2 explains the output and action taken at each step.

Fig. 2: Results and action taken at each step of the methodology.

The results of the RDC verification methodology applied to the automotive SoC are shown in Table I and Table II.

Table I. Reset Tree Analysis

Table II. RDC Analysis

Conclusion

Reset verification challenges are difficult to solve with conventional verification techniques. This new methodology can significantly help designers expedite the RDC verification process. For a more in depth discussion about reset architecture and RDC issues in automotive SoC designs and more details about the case study parameters and results, please download our paper, Systematic Methodology to Solve Reset Challenges in Automotive SoCs, originally presented at DVCon 2020, in San Jose.

Ankush Sethi is currently working as Functional Safety Manager in NXP US. He completed his B. Tech in Electronics and communication from NSIT (Delhi University) and joined NXP India as a design engineer in 2012. His areas of interest include clocking, reset, and safety architectures. Sethi holds two patents in the electronics domain and has published over 15 papers and articles in international magazines and conferences, including DVCon, DAC, EETimes, and EDN.

Aniruddha Gupta is currently working as an SoC Architect at NXP India. He earned a M.Tech in VLSI from Indian Institute of Technology, Delhi and a B.Tech in Electronics and Communication from NIT Kurukshetra. Gupta has over 10 years of experience in the SoC architecture and frontend integration domains. His main areas of interest include clocking, reset, and power management architecture, with multiple patents and several international published works in these areas.