Cách tìm và sửa lỗi siêu ổn định của thiết lập lại mềm
Most of us are familiar with the metastability problems that can be caused by clock domain crossings (CDC). Early static analysis techniques can flag these kinds of issues to ensure there are no surprises later. I spent quite a bit of time at Atrenta, the SpyGlass company, so I am very familiar with these challenges. Due to the demands of high-speed interfaces, the need to reduce power, and the growing focus on functional safety, soft resets are often used in advanced designs to clear potential errors. This practice can create hard-to-find metastability issues which remind me of CDC challenges. Siemens Digital Industries recently published a comprehensive white paper on this class of problem. If you use soft resets in your design, it’s a must read. A link is coming, but first let’s look at what Siemens has to say about how to find and fix soft reset metastability.
The Problem
As design complexity increases, systems contain many components such as processors, power management blocks, and DSP cores. To address low-power, high-performance and functional safety requirements, these designs are now equipped with several asynchronous and soft reset signals. These signals help safeguard software and hardware functional safety – they can quickly recover the system to an initial state and clear any pending errors or events. Using soft resets vs. a complete system re-start saves time and power.
The multiple asynchronous reset sources found in today’s complex designs result in multiple reset domain crossings (RDCs). This can lead to systematic faults that create data corruption, glitches, metastability or functional failures. This class of problem is not covered by standard, static verification methods such as the previously mentioned CDC analysis. And so, a proper reset domain crossing verification methodology is required to prevent errors in reset design during the RTL verification stage.
Let’s look at an example circuit that can cause soft reset metastability. A reset domain crossing (RDC) occurs when a path’s transmitting flop has an asynchronous reset, and the receiving flop has either a different asynchronous reset than the transmitting flop or has no reset at all. These two examples are summarized in the figure below.
The circuit on the left shows a simple RDC problem between two flops having different asynchronous reset domains. The asynchronous assertion of the rst1 signal immediately changes the output of Tx flop to its assertion value. Since the assertion is asynchronous to clock clk, the output of Tx flop can change near the active clock edge of the Rx flop, which can violate the set-up hold timing constraints for flop Rx. So, the Rx flop can go into a metastable state.
To review, metastability is a state in which the output of a register is unpredictable or is in a quasi-stable state. The circuit on the right shows an RDC problem from a flop with an asynchronous reset domain to a non-resettable register (NRR), which does not have a reset pin.
Note that an RDC path with different reset domains on the transmitter and receiver does not guarantee that the path is unsafe.
Also, an RDC path having the same asynchronous reset domains on the transmitter and receiver does not guarantee that the path is safe, as issues may occur due to soft resets. Different soft resets in a design can induce metastability and cause unpredictable reset operations or, in the worst case, overheating of the device during reset assertion.
There are many additional examples in the white paper along with a detailed discussion of what type of analysis is required to determine if a potential real problem exists. A link is coming so you can learn more.
The Solution
The white paper then proposes a methodology to detect RDC issues. It is pointed out that RDC bugs, if ignored, can have severe consequences on system functionality, timing, and reliability. To ensure proper operation and avoid the associated risks, it is essential to detect unsafe RDCs systematically and apply appropriate synchronization techniques to tackle any issues that may arise due to reset path delays caused by soft resets.
The white paper explains that, by handling RDCs effectively, designers can mitigate potential issues and enhance the overall robustness and performance of a design. A systematic flow to assist in RDC verification closure using standard RDC verification tools is detailed in the white paper. The overall flow for this methodology is shown in the figure below.
To Learn More
If some of the design challenges discussed here resonate with you, the Siemens Digital Industries white paper is a must read. Beyond a detailed explanation of the approach to address these design issues, data from real designs is also presented. The results are impressive.
You can get your copy of the white paper here. You will also find several additional resources on that page that present more details on RDC analysis. You will learn a lot about how to find and fix soft reset metastability.
Share this post via:
