Emerging systems have three dimensions of complexity when it comes to making them CDC-safe. First, the number of asynchronous clock domains can range from 10s to as many as 100s for complex systems with many components. Second, the primary clock frequencies vary per component. It is not uncommon for the ratio between the fastest and the slowest clocks to be greater than 10. Third, the clock frequencies themselves can change dynamically during the course of operation of the chip (for example, when switched from one mode to another for saving power). As a result, CDC verification becomes critical to ensure that metastability is not introduced in the design.

The first and second complexity dimensions above are common causes of failures but can be overcome by customizing the CDC interfaces for the given set of clocks and their fixed frequencies. The third dimension, on the other hand, requires very strict hand-shaking or FIFO-based synchronization schemes that work across the entire range of frequencies. We focus on the third dimension here and provide an example.

Let us look at the schematic shown in Fig 1. There are two clocks xmitClk (pink) and rcvClk (yellow). For simplicity, we assume all the flops in the design are posedge triggered. There is a data transfer (shown as DATA) between the xmitClk and the rcvClk domains that is controlled by the 3-flop toggle synchronizer (shown as SYNC). The toggle synchronizer has 2 flops that synchronize the control signal and a third flop to detect that a valid request signal is sent from the xmitClk domain. Notice that the output of the second flop is fed-back into the xmitClk domain (shown as FEEDBACK) to acknowledge that the DATA has been received. Once the FEEDBACK is seen, the xmitClk domain sends new DATA across the interface.

First, let us consider the case when the xmitClk domain is faster than the rcvClk domain by up to 2 times. Since they are relatively asynchronous, there could be a maximum of 2 posedges of xmitClk within any given cycle of rcvClk. With Real Intent’s Meridian formal analysis, we can determine that the above feedback structure is sufficient for the CDC interface to work correctly (irrespective of the duty-cycles and transition times of the clocks). This is because by the time the xmitClk domain receives the feedback signal, the rcvClk would have received the data.

Now consider the case when the xmitClk domain is faster than the rcvClk domain by 3 times. In other words, there can be 3 posedges of xmitClk within a given cycle of rcvClk. In this case, the xmitClk domain receives the feedback signal before the rcvClk has received the data. The xmitClk can immediately proceed to transfer new data which can corrupt the old data and/or cause metastability. The probability of failure increases rapidly as the xmitClk frequency increases. The interface can be made frequency-independent by taking the feedback signal from the 3^rd flop of the toggle synchronizer instead of the 2^nd flop (which guarantees that the rcvClk domain receives data prior to sending a feedback).

Without the fix, the CDC interface in the example clearly doesn’t work over the entire operating range of frequencies. Predictability becomes even worse when the clock frequencies are changed dynamically during the course of the chip operation (this is done in practice by applying appropriate software resets etc. carefully between the operating modes).

In order to ensure that the user does not miss any corner-case scenario, Real Intent has invented a new technology for verifying CDC interfaces with dynamic clock frequencies. It is available as the “free-running clocks” feature in the latest release of Real Intent’s Meridian (Meridian 3.0). By formally verifying the design over the entire frequency range in a single Meridian CDC run, we also simplify the otherwise cumbersome process of running the tool for each combination of operating frequencies. We make the case that a CDC tool is incomplete for modern chips without this ability to handle free-running clocks.

Feb 26, 2010