Skip to Main Content
白皮書

Techniques to identify reset metastability due to soft resets

Detect RDC issues in highly complex reset architectures

a colorful segment of a wafer
Modern SoCs are equipped with complex reset architectures to meet the requirements of high-speed interfaces with increased functionality. These complex reset architectures with multiple reset domains, ensure functional recovery from hardware failures and unexpected electronic faults. But the transmission of data across sequential elements that are reset by different asynchronous and soft reset domains can cause reset domain crossing (RDC) paths, which can lead to metastability. This metastability can cause unpredictable values to be propagated to down-stream logic and prevent a design from functioning normally. A proper reset domain crossing sign-off methodology is required to avoid metastability and other functional problems in chip designs. In this paper, we present a systematic methodology, as a part of static analysis, to intelligently identify critical reset domain bugs associated with soft resets. A soft reset is a mechanism that initiates a controlled reset within the system without fully powering it off.

A static RDC methodology to prevent silicon respins

Highly complex reset architectures in automotive designs demand a proper verification method to detect RDC issues. These RDC bugs, if ignored, can have severe conse­quences on system functionality, timing, and reliability. It is essential to detect unsafe RDCs systematically and apply appropriate synchronization techniques to tackle the issues that may arise due to delays in reset paths due to soft resets. Such action ensures proper operation and avoids the associated risks. By handling RDCs effectively, designers can mitigate potential issues and enhance the overall robustness and performance of a design.

This paper presents a systematic flow to assist in RDC verification closure using standard RDC verification tools. The Questa® RDC verification tool using this new methodology identified around 131 reset domains in the design, which consisted of 19 asynchronous domains defined by the user as well as 81 asynchronous reset domains inferred by the tool. The results of this test case are shared in the paper.

分享