The never-ending quest to kill metastability

The difficulty of an engineering problem can be gauged by two things:
1) The number of attempts to generate a solution.
2) The degree of hyperbole used to describe the effectiveness of the latest solution.

The problem many folks in the EDA industry are after right now is clock domain crossings (CDCs) and the resulting metastability of designs. Certainly the problem has gotten more difficult as designs have grown larger and use more diverse IP. The attempts to solve it have intensified, with several products being touted as “comprehensive.”

Over years of watching product rollout after product rollout, one has to wonder: if the latest version of a product is always “new and improved”, how bad was the stuff a couple generations earlier when it was christened as “new and improved”? But, I digress.

After a period of flipping through chapters of the Book of EDA Armaments and reading about the uses of the Holy Hand Grenade of Silicon Valley in the hopes of killing the fuzzy little metastability creature once and for all, a new reality seems to have set in: no one tool will do the job of analyzing and resolving CDCs in a complex design.

This is illustrated in a paper presented at the Synopsys Users Group 2013 meeting authored by Paul Zimmer. In “No Man’s Land”, he describes the problem of skew across Gray code counters used as pointers, and the difficulty in constraining paths with asynchronous clocks. After a thorough discussion of the problems, Zimmer observes:

The bottom line is that there is no easy way to automate this as a standalone piece of code. This is primarily because so much information is required about the clocks and their relationships that is not available directly as attributes. I have managed to automate it, but only using a lot of features very specific to my flow.

On top of that, Zimmer is only looking at a segment of the CDC problem – he hasn’t delved too far into other issues such as convergence. By zooming in, he has been able to hand-craft a solution for a typical problem he encounters.

There have been several attempts in developing a more comprehensive tool for CDC analysis, including Atrenta SpyGlass CDC, Blue Pearl Analyze Plus, Mentor Questa, and Real Intent Meridian CDC. Each looks through a design, trying to spot the CDC flaws based on a set of assertions and constraints, with varying levels of automation. All these tools recognize RTL simulation doesn’t uncover CDC issues, and employ different types of analysis.

The most difficult part of analyzing the CDC problem is accurately generating the assertions and constraints. As several sources point out, static checks don’t find metastability or convergence problems – but they can help with identifying and reporting information about clocks and highlight where crossings occur, which helps target areas of RTL that need to be further analyzed or modified. In an example, Zimmer points out complete clock information is hard to come by using automation, and describes adding “wrappers” to clock groups, storing information needed to understand the clock involved.

Since LINTing is a normal part of many flows, looking for more than just areas related to CDC, it makes sense that part of the solution could be implemented in a tool like Aldec ALINT. In a presentation at DAC 2013, Aldec will explore CDC and assertions generation in more detail. To reserve your seat, pre-register for Session 4: Comprehensive CDC Analysis for Glitch free Design(there’s that word again … but I think the point is, several tools work together to become a comprehensive solution).

I’ll leave the analysis and debate on the CDC analysis tools themselves to others more familiar with their capabilities. A more sophisticated CDC tool may be called for in many situations, especially in larger designs exhibiting several different types of metastability and convergence behavior. However, since the solution is ultimately hand-coding RTL, any method which spots areas of code needing help has merit – including LINT as a CDC first-pass.