{"id":288,"date":"2016-04-04T10:00:57","date_gmt":"2016-04-04T17:00:57","guid":{"rendered":"http:\/\/www.verilogpro.com\/?p=288"},"modified":"2022-09-29T00:43:29","modified_gmt":"2022-09-29T07:43:29","slug":"clock-domain-crossing-part-2","status":"publish","type":"post","link":"https:\/\/www.verilogpro.com\/clock-domain-crossing-part-2\/","title":{"rendered":"Clock Domain Crossing Design – Part 2"},"content":{"rendered":"\n

In Clock Domain Crossing (CDC) Techniques – Part 1<\/a>, I briefly discussed metastability and two methods to safely synchronize a single bit. While those techniques are commonly used, in many applications we need to synchronize multiple control or data bits, like an encoded state or a data bus. Synchronizing multiple bits brings a host of other potential problems that need to be carefully examined, and solutions that build upon the basic blocks we discussed in part 1.<\/p>\n\n\n\n

The concepts in this article are again mostly taken from Cliff Cumming's very comprehensive paper Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog<\/a>. I highly recommend taking an hour or two to read through it.<\/p>\n\n\n\n

Problems With Passing Multiple Control Signals Across Clock Domain Crossing (CDC)<\/h2>\n\n\n\n

The fundamental problem with passing multiple bits is if they are synchronized individually, they cannot be guaranteed to arrive in the destination clock domain on the same clock edge. When the individual bits are launched from the source clock domain, they may be skewed relative to each other due to trace length, process variation, etc. Since in an asynchronous clock domain crossing (CDC) the destination clock can have every possible alignment relative to the source clock (and relative to the skewed data bits), the destination clock can (and will) sample at a time when not all the bits are at their stable final values. Therefore synchronizing individual bits of a multi-bit signal is not sufficient! Let’s look at several potential problems.<\/p>\n\n\n\n

Two simultaneously required signals<\/h3>\n\n\n\n

The waveform below shows how data skew from the source clock domain can cause two signals to arrive in different clock cycles in the destination domain, if they are synchronized individually<\/i> using two flip-flop synchronizers. Don’t do this!<\/p>\n\n\n\n

Problematic clock domain crossing (CDC): two simultaneously required signals<\/a><\/figure><\/div>\n\n\n\n

Two sequenced signals<\/h3>\n\n\n\n

Individually synchronizing two signals that require precise sequencing across an asynchronous clock domain crossing (CDC) is a recipe for disaster. In fact a recent ASIC project at work had a problem like this that resulted in a chip that only booted 50% of the time, months of debug, and finally a respin (we make mistakes too).<\/p>\n\n\n\n

The waveform below shows how two separate signals that are intended to arrive 1 cycle apart in the destination domain, can actually arrive either 1 or 2 cycles apart depending on data skew. It’s difficult to even analyze the frequency difference from the source to destination clock domain and come up with a potential sequence that may work… Just don’t do this. There are better ways!<\/p>\n\n\n\n

Problematic clock domain crossing (CDC): two sequenced signals<\/a><\/figure><\/div>\n\n\n\n

Encoded control signals<\/h3>\n\n\n\n

There are many scenarios where you may want to pass a multi-bit signal across a clock domain crossing (CDC), such as an encoded signal. By now we understand the potential problem, right? Due to data skew, the different bits may take different number of cycles to synchronize, and we may not be able to read the same encoded value on the destination clock domain. You may get away with using a simple two flip-flop synchronizer if you know there will be sufficient time for the signal to settle before reading the synchronized value (like a relatively static encoded status signal). But it’s still not the best practice.<\/p>\n\n\n\n