- Chris Kwok - Mentor, A Siemens Business
- Priya Viswanathan - Mentor, A Siemens Business
- Kurt Takara - Mentor, A Siemens Business
Today’s SoC designs integrate many design IP blocks from various providers, each with their own implementation of reset. The reset architecture of a
digital design can also be very complex. Designs have multiple sources of reset, such as power-on reset, hardware resets, debug resets, software resets,
and watchdog timer reset. Errors in reset design can lead to metastability, glitches or other functional failures of the system. Furthermore, complex
interactions can occur with the convergence of multiple resets, multiple clocks and multiple power domains. In many cases, this leads to a reset tree that
is larger and more complex than the clock tree. Many of the concerns related to clock tree synthesis and load balancing now apply to the reset tree as well.
Clearly, it’s a challenge to ensure that all sources of reset propagate safely to the intended destinations under all conditions!
Traditionally, simulation has been the primary method used to verify reset behavior, often with a heavy reliance on gate level simulation. However, RTL-level simulation testing is often incomplete, and gate level simulation can only be run late in the design cycle. Even worse, typically reset-related bugs are of a very serious nature, rendering the chip completely unusable. For example, a reset bug may prevent the reset of the design to a known good starting state, making its operation completely unreliable. In more extreme cases, the design may consume too much power during assertion of reset, causing the device to overheat and be permanently damaged. All of these factors negatively combine to cause costly, late-stage design changes; and, in the worst case, multi-million dollar silicon re-spins and time-to-market delays.
We first highlight some of the common reset architecture issues that we have seen in our experience on real world designs. We will separate it into two main categories: (a) issues related to correctness of reset trees and (b) issues related to the usage of resets.
A. Reset Distribution Tree:
The first set of reset design issues are related to the incorrect implementation of resets. These problems are usually detected in the reset tree. Figure 1 shows an example—if this reset tree is incorrect, then all the other checking based on the reset sourced in the design will be incorrect, and the chip will not function properly. There is a long list of potential problems that we have seen, and we highlight two common ones here.
View & Download:
Read the entire Reset Verification in SoC Designs technical paper.