When your multi-bit synchronizer can fail! - A unique CDC scenario

I was interviewing for RTL Integration Engineer in a company. In the 5th round of that interview, I was presented with a scenario which I could not even think is possible, due to my limited exposure in this field of course. This might not be nothing new for someone who is working on CDC for a considerable amount of time.

The interviewer asked me how I can ensure synchronization of a multi-bit signal/bus. The obvious answer to this will be an asynchronous FIFO or a handshake-based synchronization. The interviewer further asked me what is guaranteeing that all the bits of the bus are reaching the destination at the correct time? This was enough to get me confused. I just said - I do not follow.

He then explained the scenario to me in detail. He said that there is a possibility that the length of traces of each bits in the bus are not equal in length (after the chip is manufactured). Due to this, the value of some of the bits can get sampled first, and the bits which has a longer trace length will get captured in the later clock cycle.

Neither asynchronous FIFO, nor handshake synchronization will work in this scenario. If we are using asynchronous FIFO, wrong value of the bus bits can get stored in FIFO because few bits are getting sampled at the next clock cycle. If we are using handshake synchronization, the ready signal from sending domain might reach the destination before some of the bits in the bus, hence corrupting the data getting captured in destination domain.

After the interview, I researched a bit and found a paper which talks about a similar issue in detail. I will link the paper at the end of the article. I suggest you to through it so that you can at least have a short conversation regarding this issue.

The good news is – It is not entirely an RTL issue! Generally, when the back-end team does the timing analysis for asynchronous signals, they use a blanket false path or multi-cycle path constraint for those signals. Due to this, there is nothing guaranteeing that the bits in the bus have a common trace length. The person doing the routing, or the routing tool does not know that certain bits are a part of the common bus and hence does not care if they have a common length or not.

The paper talks about how we can use the constraints effectively to avoid this issue. It also discusses a rather tedious process of how RTL team can give feedback to the back-end team so that they can ensure the bits in a bus have a common length.

Find the paper here: A New Approach to Easily Resolve the Hidden Timing Dangers of False Path Constraints on Clock Domain Crossings

Hope you learned something new. See you in the next article!