Faster reset verification closure with intelligent reset domain crossings detection

An RDC verification solution

The increased functionality, multiple interfaces, performance optimizations, and multi-mode operations in modern system-on-chip (SoC) designs have led to highly complex architectures of multiple primary reset sources, splitting the chip into several reset domains, each receiving different combinations of primary reset sources. In order to ensure that signals crossing complex reset domains function reliably, advanced reset domain crossing (RDC) verification, as part of comprehensive static analysis of the RTL, is imperative. An RDC verification solution must not only identify asynchronous, reset-assertion induced, critical metastability issues at reset domain crossings and glitches due to combinational resets, but also ensure reliable and accurate RDC reporting for quick verification turn around.

In recent years, higher IP reuse, increased functionality, and high-speed interfaces embedded in modern SoCs have given rise to complex reset architectures due to segregated regions that require frequent reset sequences independently. In order to bring a design to a known state, a power-on-reset strategy, also called a cold reset, for the entire system is deployed in the event that a power supply is unavailable. Apart from this, other reset strategies— including hardware resets, debug resets, software resets, and watchdog timer resets—are required to keep certain functionality, such as timekeeping and calendar features, up and running or maintain system RAM or other secure blocks in an active state to retain values when software requests the system go into global reset, also called warm reset. Hence, different parts of the system have different reset requirements and owing to the complexities of SoC designs, which have a large number of reset sources creating a complex reset architecture along with its convergences with multiple clock and power domains while driving higher flip flop counts, can cause metastability issues at the crossings of different reset domains.

Such reset related bugs are known to cause unpredictable reset operations or, in the worst case, overheating of the device during reset assertion. These issues are not covered by standard, static verification methods such as static timing analysis or clock domain crossing analysis. The gate-level simulations used to verify reset behavior runs too late in the design cycle. Any late-stage design changes resulting from gate-level simulations may prove expensive and, in the worst cases, result in silicon respins. Hence, a reset domain crossing verification methodology is used to catch these bugs earlier, during the RTL verification stage.