Clock Domain Crossing (CDC): Are We There Yet?

If functional CDC issues haven’t stalled your designs yet, you’ve been lucky. But odds are good they will.

popularity

Over the last decade, SoC designs have become significantly reliant on IP reuse to manage the design complexity and meet time-to-market goals. IP-based design and verification methodology is essential but has put an additional verification burden on IP suppliers (internal and external). IP suppliers need to ensure that their IP is exhaustively verified and SoC Integrators need to ensure that all IPs are talking to each other according to defined protocols. Design complexity and IP reuse have brought asynchronous clock domain issues to the forefront of verification. Clocking issues are the second most common reason for costly design re-spins. This has been the driving factor in the ever-increasing demand for Clock Domain Crossing (CDC) analysis tools.

Today, the majority of IP and SoC teams are focusing on “Structural CDC” analysis, which is important but not sufficient by itself. Structural CDC analysis only ensures that the design has the structures (e.g. synchronizers) in place to ensure metastability effects (caused by asynchronous clocks) are managed well. In addition to structural analysis, designs also need to adhere to pre-defined (functional) CDC protocols to ensure safe data transfer across asynchronous clock domains. Let us call this Functional CDC. To describe Functional CDC in simpler terms, we can equate CDC structures to roads, data to cars, and traffic lights to pre-defined Functional CDC protocols. To ensure the smooth and safe movement of cars from one point in the city to the other, traffic lights need to be adhered to. If not, accidents and traffic slowdowns will cause gridlock.

aneja1

Here are some examples of traffic light Functional CDC protocols:

  1. Any value change on a signal in the source domain needs to be asserted long enough to be sampled correctly in the destination domain.
  2. For a data crossing enabled by a control path, data needs to be stable when the enabling control path is active (See picture below).

Untitled

The next question is how these Functional CDC protocols can be verified. There are two approaches to verify functional CDC protocols:

  1. Formal-driven Verification.
  2. Simulation-driven Verification.

Formal analysis has its advantages—no test bench required, exhaustive verification etc. However, it requires an upfront understanding of what the designer wants to achieve out of the analysis and a plan to accommodate the required time and resources. For the same functional CDC protocols, SVA (System Verilog Assertions) can be generated and simulated with the RTL simulation regressions. Simulation is not exhaustive but it reduces the barrier to adoption.

Whether you are using formal, simulation, or both, these critical Functional CDC issues need to be addressed. Otherwise, it’s like having your kids in the back of that car constantly asking, “Are we there yet?”

No, you are not there. If functional CDC issues have not stalled you yet, you have been lucky. With ever-increasing design complexity and IP reuse, you may run out of luck faster than a deer crossing a busy freeway!!

In the next blog, I will talk about what it takes to make formal analysis flows efficient and productive for verifying Functional CDC protocols. Stay tuned!!



Leave a Reply


(Note: This name will be displayed publicly)