SV Blog SystemVerilog Blog
Related Articles
Introduction
I have seen many promising candidates over the years and I want to make sure that before you come in for an interview for a non entry level FPGA engineering position that you have what it takes to pass. This will get technical.
You’ve passed a phone screen and are now sitting in the interview room.
You’ve gotten this far because you showed promise on your resume and intelligence talking to one of us over the phone. Now is the moment of truth when we can sit down and whiteboard some problems. I do really want you to pass this interview, but this is the point where most of the candidates I’ve talked to stumble and fall.
Over a number of blog posts, I want to present a set of questions that I have used in the past, why I use them, and why I think you should know it.
Questions 1:
I assume that you have designed using multiple clocks. I have a signal that I need to get from one clock domain to another. Assume that you have as much time as you need on the receive side to detect the signal and that it will change infrequently, how would you make sure that the crossing is safe?
Why do I ask this question:
Synchronization is a basic aspect of design. A person with experience who doesn’t understand this basic concept can easily make extremely hard to find mistakes and thus they really need to understand why it’s important, what goes wrong if it’s not correct and how to do it correctly. The sad fact about most college grads that I’ve spoken to is that professors completely overlook teaching this and most new grads do not have a good handle on this or may never have heard of it. I can give a partial pass to a new grad if I’m hiring for a position where the time can be taken to mentor.
AnswerDouble registering the signal on the target clock domain is the simplest and correct answer, at least for the clock speeds that are used in FPGAs currently. I’m not sure when you scale up to multi-Ghz ASIC designs what they use, I’d love to hear.
Why does this work?
The answer is in metastability of a flip-flop (FF). As you should know, a FF has two timing parameters associated with the relationship of input data to the clock, Setup and Hold. In a synchronous design, the designer will construct his data and control paths so that the signals are there in enough time to meet setup and the tool will balance clock trees to ensure that hold times are met.
In a true asynchronous crossing, these parameters are impossible to meet and at some point in time the signals being clocked at the receiver will violate the setup or hold times of the FF and it will go metastable. Every cell has a settling time, so eventually the FF will either revert to the old value or transition to the new one. If you were to take this metastable flop and run it into two different destination FFs with differing data delays, this could mean the receiving FFs could see two different values!
Proper Synchonization
Thank you for mentioning this. The explanation is pretty solid. I have a follow-up question, however.
Isn’t it unsafe to use the concept of dual flop registering when multi-bit signals are crossed from one clock domain to another?
When you cross over a multi-bit signal, some flops might settle to a new value, and other flops might not. This would lead in crossing over a value which might not correspond to a previous or next state (unknown).
If the above statement is true, are asynchronous FIFOs the only option to facilitate safe crossover of multi-bit signals?
Also, I believe the path corresponding to the asynchronous transfer needs to be declared as false path?
Asssuming there are several data crossings between two clock domains, would it be a good idea to declare false path on the basis of two clocks rather than declaring it on the basis of each individual net?
Thank you,
VK
Hi VK,
Check out post #3 regarding passing control buses. Short answer is to never clock multi-bit signals multiple times for exactly the reason you posted. You should pass a single control signal that says the data has been latched at the source and is stable. Then by the time you synchronize the control signal, it is safe to capture the bus in the receiving clock as long as your constraints are correct. I’ll do a post on this by the weekend since this has been brought up on linked in too.
Thanks for commenting! I hope this helps you.
-Frank