Requirements For Exhaustive SoC Reset Domain Crossing Checks

It is common to read that the numbers of clock domains and power domains in system-on-chip (SoC) designs are increasing, but for some reason there is less discussion about resets. There is no doubt that the number of reset domains is also rising; studies have shown that the single reset of twenty years ago has been replaced by a complex network of 40-50 domains in many chips and even 150 in some cases. Resets perform many important functions in a chip, from clean initialization of state values to recovery from unexpected scenarios such as deadlocks and transient errors. Power management techniques that turn parts of a chip off and on also rely on predictable resets.

There are multiple kinds of resets in SoC devices. An externally applied power on reset (POR) is the most familiar since it may stem from a user pressing a button. However, there are many internally generated resets occurring when either hardware or software determines that reset is needed, and these typically affect only specific parts of the chip. For example, waking up a powered-down function begins with a reset. Many of these functions have unique resets, and any portion of the chip with a unique reset signal is defined as a reset domain.

Every time that a signal traverses from one reset domain to another, this creates a reset domain crossing (RDC). Designing and implementing reset domains is challenging, with many opportunities for errors. Most RDC bugs are impossible to fix in a fabricated chip, so thorough pre-silicon verification is essential. SoC teams used to rely on simulation to detect RDC errors, but that approach is inherently slow and incomplete. Further, many internally generated resets are not easily controlled from the chip inputs. Powerful and exhaustive static RDC checks are mandatory for any SoC with multiple reset domains.

There are many requirements for RDC checks to be effective, and these must be considered seriously by any engineer looking to select a commercial solution for reset verification. Design capacity and complexity are critical. Some legacy RDC tools boast about handing a few million gates with five levels of sequential elements, but this is not nearly enough for modern SoCs. The chosen solution must be able to handle billions of gates and perform “any depth” analysis, including paths through the layers of non-resettable registers commonly used in pipelined datapaths.

It is essential that the RDC solution accept industry-standard Synopsys Design Constraint (SDC) files to guide the analysis and ensure accurate results. Constraints specify important attributes of the design such as clock patterns and reset sequencing rules. Since RDC analysis is run at multiple stages during chip development, it must be robust enough to produce useful results even when the design register transfer level (RTL) code or SDC file is incomplete. In fact, robust and powerful engines are mandatory for every step of RDC verification.

It must be possible to reuse existing SDC files for logic synthesis and static timing analysis, minimizing the need for tool-specific specification effort. The RDC solution must be able to leverage advanced constraints that identify where clock gating logic and isolation cells between domains will be inserted during synthesis or place and route (P&R). Similarly, the solution needs to be capable of reading IEEE Std. 1801-2015 Unified Power Format (UPF) power intent files that define power domains and other aspects of low-power design.

As the RDC solution reads in the SDC and UPF files, it must interpret them in the same way as the synthesis and P&R tools. It is essential that the RDC internal model insert isolation cells, clock gating cells and other power-related structures so that they are taken into account during analysis. Thus, as shown in the figure, if an isolation cell on an RDC signal prevents signal transitions and therefore metastability, no violation will be reported. Support for the standard Tcl scripting language is also mandatory, so that users can query the design, filter results and generate customized reports.

It is important to remember that RDC analysis is just one of the many steps in chip verification, so a standalone point tool is highly undesirable. The RDC solution should share a user interface with other types of checks (lint, clocks, power, etc.) and integrate tightly with an industry-standard debug environment. Debugging an RDC violation should feel very much like debugging a simulation failure. The RDC solution must also assist in the debug process by building a word-level internal model, intelligently clustering related violations and enabling user filtering interactively as well as in Tcl files.

Synopsys VC SpyGlass RDC is the only industry solution that meet all the requirements listed above. It has been run successfully on massive SoCs that competitive tools can’t even read in. Performance is typically four times that of legacy solutions. It provides an unrivalled solution for reset verification, with Tcl, SDC and UPF support, exhaustive static analysis, low-noise results and debug in the industry-standard Verdi Automated Debug System. Finding RDC errors at the RTL stage is part of the industry “shift left” in verification. The number of chip resets and reset domains continues to grow, making this solution a requirement for every SoC project.

For more information, a white paper is available.