The Problem with Reset Domain Crossings

Design complexities in reset, like everything else in big SoC designs, has become incredibly complex, for all sorts of reasons. Long, long ago reset was something you just did once, when you turned the power on. Turn on, then hold reset for some amount of time until everything is in a known starting state, and off you go. Nice and simple.

Then we found we had to handle multiple clock domains – for the CPU, the PCI, USB, SPI, etc, etc I/Os and you couldn’t just run the same asynchronous reset into each of these because you create metastability problems when it de-asserts, essentially the same kind of metastability you can get in clock domain crossings.

(Then you get into questions of synchronous or asynchronous resets, or asynchronous assert and synchronous de-assert, a topic which always seems to provoke debates of near-religious fervor among the reset cognoscenti. I’ll leave it to them to battle that out.)

Resets became fragmented not just to deal with clock domains but also to manage more refined reset needs. Now reset isn’t just the big red button to reset the whole darn thing but also allows for selective reset. Maybe I just want to reset this block because it’s misbehaving, and I want to get it back on track. This is a technique that is really blossoming in ASIL-D compliant designs where a safety island regularly monitors status of sub-functions (e.g. AI accelerators) and will isolate and force a reset of misbehaving functions.

Resets may also need to be sequenced on bring-up (not a lot of value in resetting other logic until the CPU cluster has booted). Then I want to manage reset in a controlled and orderly way to get everything to a reasonable start state.

Then there’s the interaction of reset and power management. For isolation between blocks in different power domains, if the isolation control signal is generated by a device in a different reset domain than the block on the downstream side of that isolation, then you have a reset domain crossing and potential problems.

All of which underlines that the good old days of a reset being one wire, with a fanout all over the chip, are long behind us. Now reset is another bundle of complex control logic, ultimately driving smaller traditional fanout trees in their own respective domains. And crossing between those domains must be proven to be safe. Simulation is a tough way to do that – static analysis is the more common approach to ensure as complete coverage as possible.

Synopsys recently released a white paper on VC SpyGlass RDC with their views on the origins of potential RDC problems and their views on checking for these problems. They mention particularly VC SpyGlass RDC ability to do this analysis together with UPF, which I would think would be a must-have to ensure an RDC-clean design in virtually any modern SoC. VC SpyGlass RDC also natively reads design SDC, another must-have in ensuring clock and other definitions are accurate. All of this works with Verdi, as do other functions in VC SpyGlass, so you can debug RDC problems in a very familiar environment.

You can learn more about VC SpyGlass RDC HERE.

Also Read

What’s New in CDC Analysis?

SpyGlass Gets its VC

Prevent and Eliminate IR Drop and Power Integrity Issues Using RedHawk Analysis Fusion