User Case Study

Whenever more than one clock is employed in an SoC (which is all SoCs), the risk of errors from clock domain crossings (CDC) – signals (or groups of signals) that are generated in one clock domain and consumed in another – is incredibly high. Unfortunately, CDC bugs are nearly impossible to catch with conventional simulations. Thus, all too often they escape into silicon. Debugging them in the lab is no picnic because CDC failures are so intermittent, making them difficult to reproduce and debug. Even worse, this pernicious class of failures is only exacerbated by the addition of low power control logic.

Fortunately, at Mentor’s recent User2User conference in Bangalore, India, ARM engineer Praveen Kothanath shared how he was able to apply formal-based CDC tools and methodologies to identify and fix more than 20 “regular” and low power Dynamic Voltage Frequency Scaling (DVFS) design-driven CDC issues well before tape out. Here are the highlights:

* DUT in question
— SoC with multi-million gate internal IP blocks
— Multiple power and clock domains
— Strict low power performance requirements across all IPs, and the system as a whole
— Consumer electronics end-market = very high volume production = very high cost of failure!

* Low Power Architecture Highlights
— Low power architecture included Dynamic Voltage Frequency Scaling (DVFS) circuitry
— Dynamic frequency scaling defined: scaling the frequency of a microprocessor “on the fly” to conserve power, or reduce the amount of heat generated by the chip.
— Dynamic voltage scaling defined: the voltage(s) used on a microprocessor can be increased or decreased “on the fly”, depending upon circumstances
— Both methods can be simultaneously combined, hence the use of the term “Dynamic Voltage Frequency Scaling (DVFS)”
— Power intent was captured by UPF 2.0 file

* CDC Verification flow
— The “structural analysis” flow with Questa Power Aware CDC is itself is very straightforward. Simply assemble and compile all the design libraries (including the UPF file), list all the clock and reset signals, define any constraints, then run the analysis.
— Potential gotcha #1: Praveen highlighted the risks in not modeling non-synthesizable models (memories, DDR PHYs, PLLs, etc) where CDC bugs may be missed. These macros are easily described by importing the timing information from Liberty files with the Questa CDC Liberty import feature — problem solved.
— Potential gotcha #2: The tool can automatically identify all the clocks and resets, and naturally it’s incredibly tempting to just go forward with the tool’s generated lists. However, this team opted for a more conservative approach by defining the clocks and resets manually by physically reading engineering spec, and comparing their inputs to the Questa generated signal lists. In this way, for the cost of a little leg work they were able to implicitly verify the RTL matched the actual spec.
— Potential gotcha #3: It bears repeating that special attention must be given to clocks that are crossing power domains given that the power control structures could introduce CDC paths. In a nutshell, domains which are powered by different supply net should be made asynchronous.
— Potential gotcha #4: Analyze the warnings that the tool gives early to avoid surprises.

* Results: with Questa Power Aware CDC, Praveen and his team found over 20 CDC failures that would have otherwise made their way to silicon

Taking a step back, success stories like this one, where automated tools like Questa CDC leverage the exhaustive nature of formal analysis under-the-hood to tame once intractable problems are becoming more common by the day. In this case, Questa Power Aware CDC is clearly the right tool for this job.