From electronic toys to DVD players, cell phones, and communication satellites, a broad array of products benefit from ASICs. So much so that ASICs, which help to control how an electronic device will function, have grown as large as billions of gates to support increasingly demanding features and functions. As a result, multi-billion-gate ASICs can boast dozens or even hundreds of clock domains to support multiple third-party IP blocks, external interfaces, and power-saving functions of variable frequencies.
The interplay of these clock domains with power management techniques and new low-power logic can potentially introduce bugs late in the chip design cycle, making it more difficult, costly, and sometimes even impossible to resolve. There are also complex paths and scenarios deep in the design where bugs may lie undetected, potentially leading to costly design re-spins.
What are the best ways to address power-aware clock domain crossing (CDC) challenges in today’s large, complex chips, while achieving faster design closure?
With increasing SoC complexity comes increased importance to verify the correct construction of RTL, CDC, as well as reset domain crossing (RDC) early in RTL development. Doing so helps to achieve faster—and predictable—design closure. In this blog post, we’ll discuss a power-aware CDC and RDC methodology that STMicroelectronics (ST) used to achieve faster turnaround time and better quality-of-results for CDC and RDC structural checks.
A clock domain represents a part of a design that’s driven by one clock or multiple, related clocks. To reduce power, clock logic often is used to operate the chip at a high frequency and to turn off its inactive parts. CDCs happen whenever a signal crosses from a source clock domain to a destination clock domain, with both clock domains being asynchronous with each other. Asynchronous clocks, as well as reset domains, provide a mechanism through which various IPs in a chip can interface with each other. The more timing variation between the two clocks, the greater the chance that unpredictable behavior could emerge.
A key problem for designs with asynchronous clocks is metastability, the best-known consequence of CDC. Consider a signal from a source clock domain that enters the destination clock domain. If this signal changes value closer to the destination clock edge, it could violate the setup and hold time of the resulting flip-flop, which would then cause it to enter a metastable state. Circuit metastability can trigger a system failure.
Low-power techniques can also introduce metastability. This is particularly true when the power-management infrastructure interacts with signals that cross clock or reset domains, leading to additional CDCs or breaking already synchronized, pre-qualified paths (and, thus, causing silicon bug escapes). These techniques can also cause glitches or convergence issues.
A reset domain is the part of the chip with a unique reset signal. A signal traveling from one reset domain to another creates an RDC, which can be susceptible to metastability. Asynchronous resets have grown more common due to more prevalent use of multiphase power-up/boot sequences and similar techniques. This means that we’re also seeing more design errors stemming from RDCs.
CDC and RDC verification are among the toughest verification challenges that SoC designers encounter. Why? With the size of today’s SoCs, the potentially hundreds of asynchronous clock domains cannot be effectively verified using traditional simulation or static timing analysis (STA) tools. Functional simulation at RTL isn’t intended for verifying metastability effects that lead to data transfer issues across asynchronous clock boundaries, while STA simply doesn’t address asynchronous clock domain issues.
Turnaround time can be slow, too, with traditional tools. Running a full-chip, flat-level CDC analysis on a multi-billion-gate ASIC with potentially millions of CDC clock crossings could take months of compute time and need terabytes of memory.
There are other challenges to consider. Given the number of CDC clock crossings (millions!) in a large design, there’s the possibility of a substantial number of violations. In the midst of the violation white noise, pinpointing those violations that will lead to real problems is difficult, especially when done manually. Constraints and waivers must be inputted and identified correctly; otherwise, the resulting CDC analysis will be inaccurate and errors could be masked.
Designs typically don’t have as many RDC errors as there are CDC errors. However, in final silicon, RDC errors can be challenging to identify, debug, and root cause, making it ideal to ensure that RDC analysis is done during the earliest RTL development stages. RDC paths have the potential to cover long chains of sequential logic. To prevent RDC metastability, RDC analysis should be designed to perform a global analysis across a design to detect reset-less structures on these sequential paths. Potential RDC paths can be protected with qualifier signals and blocking gates.
There are some similarities between CDC and RDC verification. Setup is, once again, critical, as incorrect constraints and waivers could trigger false negatives or false positives. White noise is also a problem on the RDC side, making manual analysis burdensome.
ST, headquartered in Geneva, Switzerland, develops chips for a broad variety of industries, including automotive, industrial, consumer, and the IoT. The company’s CDC-RDC verification engineering team had been using previous-generation RTL signoff tools. However, for their larger and more complex chips, the team needed even greater accuracy and more exhaustive analysis without any penalty on speed. That’s when ST evaluated Synopsys VC SpyGlass® RTL Signoff Platform, a part of the Synopsys Verification Family. Building on the proven SpyGlass technology, the power-aware, constraints-driven VC SpyGlass solutions verify correct construction of RTL, CDC, and RDC in the early RTL development stages of a design. The technologies are compatible with Synopsys Design Compiler® RTL synthesis and Synopsys PrimeTime® signoff use models and feature native Synopsys Verdi® Automated Debug System integration for lint-, CDC-, and RDC-centric debug. With advanced algorithms and analysis techniques, designers gain insights early enough to prevent costly errors downstream.
The ST team’s test case using VC SpyGlass technology consisted of four main tracks: one with a clock selection element, one with a black box (a cell whose logic functionality is not known to the tool), a third track with two converging CDC paths, and a fourth track with power and voltage domain crossings.
“Using Synopsys VC SpyGlass technology on our large SoC, we achieved 3x to 4x faster verification performance compared to our preceding CDC/RDC verification environment,” said Jean-Christophe Brignone, senior member of the technical staff, CDC-RDC Verification at ST. “The accuracy of the products for convergence analysis, their exhaustive coverage for RDC analysis, and their use of machine learning to cluster violations for root-cause analysis make the verification experience efficient, with high-quality signoff and high debug productivity.”
With increasingly large SoCs comes the implementation of low-power techniques that can bring with them some nasty chip-killing bugs. Traditional functional simulation and STA aren’t intended to address the asynchronous clock domain-related issues that stem from some of these low-power techniques. However, as ST found, a power-aware, RTL-level CDC and RDC verification methodology is keenly adept at finding CDC issues that stem from new low-power logic introduced at the RTL stage and also for providing smarter, faster low-noise reset verification (RDC). With Synopsys VC SpyGlass RTL static signoff technology, ST experienced faster verification with better accuracy, results, and ease-of-use.
Dive deeper into CDC/RDC verification by watching our on-demand webinar, “Constraints-Driven CDC and RDC Verification Including UPF-Aware Analysis.”
You can also find additional insights here: