Blog: Clock Domain Crossing in Agnisys IDesignSpec

Here’s a further insight into the Agnisys tools…
—
In my previous blog I introduced you to Agnisys IDesignSpec, the class leading solution for automated register model generation. In this blog, I would like to share with you IdesignSpec’s support for Clock Domain Crossing.

It is not going to be a surprise to today’s designers, that with SoCs becoming more complex, increasing functionality means frequent data transfer from one clock domain to another, and without employing proper techniques, will lead to metastability issues.

Within one clock domain, proper static timing analysis (STA) can guarantee that data does not change within clock setup and hold times. When signals pass from one clock domain to another asynchronous domain, there is no way to avoid metastability since data can change at any time.

By not addressing and verifying CDC errors early in the design cycle, many designs exhibit functional errors only late in their design cycles or during post-silicon verification. Several coverage metrics exist to measure the validation’s adequacy and progress, such as code-based coverage, finite state machine coverage, and functional coverage. Nevertheless, these coverage metrics do not have direct relations with CDC issues.

To address clock domain problems due to metastability and data sampling issues, designers typically employ several types of synchronisers. The primary responsibility of a synchroniser is to allow sufficient time such that any metastable output can settle down to a stable value in the destination clock domain. The most common synchroniser used is based on the well-known two-flip-flop circuit. Other types of synchronisers employ handshaking protocols or FIFOs. In a limited number of cases, it may be useful to use dual-clock FIFO buffers or other mechanisms optimised for domains with similar clock frequencies.

In layman terms; a synchroniser is a digital circuit that converts an asynchronous signal from one clock domain to a different clock domain, capturing it without introducing metastability failure. However, the introduction of synchronisers does not guarantee prevention of metastability. It only reduces the chances of metastability by a considerable factor. Thus, a good synchroniser must be reliable with high Mean Time Between Failure (MTBF), should have low latency from source to destination domain and should have low area/power impact.

IDesignSpec supports Clock Domain Crossing from both the software side and hardware side.

CDC from the hardware side

On the hardware side, there are two ways of addressing Clock Domain Crossing (CDC) issues. These are:

• CDC without handshake
• CDC with handshake

In this blog, we will see CDC flow without a handshake to resolve CDC issues on the HW interface:

CDC without handshake

Here synchronisers are used in Hardware input/output domain with respect to the IDesignSpec generated slave. A Flop synchroniser, synchronises input from the Client to Hardware(H/W) interface. And MUX synchronisers are used for synchronisation from H/W interface to the Client.

Fig 1: CDC without handshake

Using the ‘cdc.clock’ property on registers or field in IDesignSpec; the user can generate the above synchronisers shown in Fig 1

cdc.clock=<h/w_clock_name>

This property has been applied on the Reg1 in IDSWord as shown below:-

Using the specification above; the Flop Synchroniser and Mux Synchroniser gets generated.

At FirstEDA, we also support Aldec ALINT-PRO, which can help you pick such CDC issues earlier on in the design cycle and save you on having multiple spins of the design. Below is the snippet of ALINT-PRO analysing the design for CDC

Yes, ALINT-PRO has spotted the synchronisers that are present in the crossing!! This topic is clearly of great interest to both design and verification engineers; hence I hope to talk about it in greater depth in my upcoming posts.