Al Joseph Sr. Applications Consulting Engineer
As a Graduate from the University of Portland with a BSEE in Computer engineering, Al has used his education as a starting point for his 20 plus years of experience in the EDA industry. His tenure in the industry has been focused in technical sales, technical marketing and methodology consulting. … More »
CDC (Clock Domain Crossing) Analysis – Is this a misnomer?
February 15th, 2010 by Al Joseph Sr. Applications Consulting Engineer
The high-tech industry is chock-full of acronyms. Each time a new problem is identified, out comes a new acronym that quickly gets standardized. It is very typical for complex new problems in, for example, our VLSI design industry to take years to understand and solve fully. Unfortunately, in many of these cases, the new acronym gets co-opted by a premature solution or a solution to a subset of the actual problem rather than be associated with the fundamental problem itself. The end result can be confusion and miscommunication as customers who use these incomplete solutions with the fancy acronyms do not realize that their problem is not fully solved and end up with project failure.
A revealing instance of this phenomenon is CDC – Clock Domain Crossing – analysis. As asynchronous crossings became more mainstream because of larger dies and greater system-level complexity on chip, it became clear that managing metastability was of paramount importance. The analysis of the design for proper metastability management came to be known as CDC analysis. Unfortunately, early solutions for CDC analysis only verified single-bit metastability management (synchronizers implemented as back-to-back flops) and data-bus metastability management (controlled by a synchronized common enable signal). Designers’ understanding of CDC analysis even up to this day, as CDC analysis has become mission-critical for SOC designs, is that it only requires checking these two attributes.
In reality, the above two checks are just the tip of the CDC analysis iceberg. To begin with, they represent only a limited checking of metastability management. In addition, clock domain analysis must check for many more issues than just metastability management like the ones listed here:
- Data correlation when you have fast to slow clock crossings
- Cycle jitter tolerance in data crossings
- Cycle jitter in control crossings
- Glitch issues even when control busses are gray coded
- Glitch issues with clock gating implementation
- Re-convergence of signals synchronized separately to a single clock domain
- Correct implementation of asynchronous FIFO protocols
- Correct implementation of resets that cross multiple domains
As with metastability verification, all of the above issues are very difficult to characterize and verify with simulation-based techniques. There have been many silicon re-spins as a result of not comprehensively verifying the above issues. Examples of failures we have seen happen in practice are quite revealing:
- An asynchronous reset-control that crossed clock domains but was not synchronously de-asserted, causing a glitch in control lines to an FSM
- Improper FIFO-protocol controlling an asynchronous data crossing resulting in a read-before-write resulting in functional failure
- Reconvergence of synchronized control signals to an FSM that were not gray-encoded, resulting in cycle jitter that, in turn, caused a transition to an incorrect state
- Glitch in a logic cone on an asynchronous crossing path that was latched into the destination domain resulting in corrupt data being captured
- Gating logic inserted by back-end tools for power management resulted in glitches on a clock
Verifying the above issues must use a combination of structural analysis and static formal property checking. Older tools that do only a limited amount of checking but continue to use the CDC moniker do the customer a disservice. They also do a disservice to modern tools like the Meridian product family from Real Intent that provides the most comprehensive analysis of CDC related issues. Meridian does this by identifying all asynchronous crossings, verifying proper metastability management in crossings, comprehensively verifying that logic in asynchronous crossings is glitch free and by verifying asynchronous crossing control protocols. Since logic is inserted by back-end tools into clock nets, it is important that the tool be able to run on a netlist. Meridian is the only CDC tool that can be run on netlists as well as on RTL, recognizing all asynchronous crossing controls including FIFO’s. Meridian is also the only tool that enables CDC checks to be performed in simulation in addition to static structural and formal analyses.
So, beware of acronyms! Make sure you know what they really represent.
One Response to “CDC (Clock Domain Crossing) Analysis – Is this a misnomer?”