Avoid setup- or hold-time violations during clock domain crossing
Article By : Deekshith Krishnegowda, Marvell Semiconductor
To avoid data loss, designers need to ensure that setup- or hold-time violations don't occur during clock domain crossing.
The modern ASIC consists of millions of gates and billions of transistors that often can be operating in several domains having different voltages and clock frequencies. To avoid data loss, designers need to ensure that the signals sent from one domain to another do not cause setup- or hold-time violations for registers in the destination domain. Here are 10 things to ensure or avoid while crossing clock domains.
A setup or hold time violation for registers in the destination domain, typically flip-flops, can cause the flip-flop to enter a condition known as metastability. You can read Understanding Clock Domain Crossing Issues to learn more about issues with crossing clock domain and how it causes metastability, but the key point is that synchronizing the signals crossing domains is an absolute must in any design. The circuit that handles this task, referred to as a synchronizer, might employ one of several different synchronization schemes based on the specific domain conditions. You can find more details about these schemes in the article Synchronizer techniques for multi-clock domain SoCs & FPGAs.
Even when using these techniques, however, there are several things you will need to do, and several things not to do, to avoid design issues with synchronization.
Use multistage synchronization
Using only a single flip-flop to synchronize signals crossing a clock domain faces a high risk of failure by passing metastability (Figure 1a), especially if the difference in domain clock frequencies is high. It is better to use a two-flip-flop synchronizer as shown in Figure 1b or even a three-flip-flop synchronizer. Using a two- or three-flip-flop design gives more time for the signal crossing domains to stabilize after it enters metastability.
Figure 1 Using two or more flip-flops as a synchronizer will avoid propagating any metastability caused by timing errors at the receiving end.
Avoid combining signals from early synchronization stages
Because the first flip-flop in a multi-stage synchronizer can enter a metastable condition, never use the first flip-flop’s output as a logic input to any cells (Figure 2). Doing so risks the transmission of metastability in your design.
Figure 2 The output of a synchronizer’s first flip-flop should never be used for any downstream logic other than input to the second flip-flop.
Register combinatorial signals before synchronization
If the signal crossing the clock domain is coming directly out of combinational logic, it may have glitches in it. These glitches can reduce the two-flip-flop synchronizer’s mean time before failure (MTBF). Registering to the source clock the signal that will be crossing a domain removes glitches (Figure 3). To help preserve the synchronizer’s MTBF, then, always register a combinatorial signal before crossing domains.
Figure 3 A simple two-flip-flop synchronizer may capture glitches coming out of combinatorial logic, so register any combinatorial signal in its transmission domain before it crosses clock domains.
Account for metastability delay
When crossing multiple bits using a multibit synchronizer, always account for metastability delay. Any bit that experiences metastability when the flip-flops clock will not be fully synchronized until the next clock cycle. Because of this delay, there is no guarantee of either the coherency or the order of data synchronization. Instead of using two-flip-flop synchronizers as shown in Figure 4a, use another form such as a data multiplexer, an asynchronous FIFO, or the like. If, however, the bus is grey code encoded as shown in Figure 4b, then we can use a multibit synchronizer because only one bit is changing at a time. Just make sure to register the bus before crossing domains because gray encoding is fully combinational logic (see the tip above).
Figure 4 A two-flip-flip synchronizer (a) can lose synchronization due to metastability delay so should not be used. Using binary to gray encoding before crossing the domain and gray to binary decoding afterward (b) solves this problem.
Ensure sufficient clock rates
The clock period in the signal sending domain should be at least one and one-half times the receiving domain’s clock period. Too short a sending clock period can result in the signal not always being sampled. If this condition cannot be satisfied, then it is better to use a request-acknowledge kind of mechanism to control the toggling of the signal that is crossing domains.
Never assume synchronization
When using a net or bus from another designer’s block in a domain, do not assume that the net is synchronized for you. Always check and use synchronizers if necessary.
Synchronize feedback signals
Be cautious when using the output of the first flip-flop in a synchronizer to reset the flip-flop in transmitting clock domain (Figure 5a). This may cause a timing violation outside of the synchronizer or can pass metastability. It is better to also use a synchronizer on such a reset signal when it crosses domain, as shown in Figure 5b. This will ensure that the flip-flop in the sending domain does not violate any timing rules.
Figure 5 Use a synchronizer on any reset signal from the receiving domain that targets a flip-flop in the transmission domain.
Avoid logic between synchronization stages
Avoid placing any combinational logic in between flip-flops of the synchronizer as it may reduce the synchronizer’s MTBF (Figure 6). The output of combinational logic may glitch and cause timing problems which will eventually lead to metastability.
Figure 6 Combinational logic between two flip-flops of the synchronizer will reduce its MTBF.
Synchronize software-driven signals
Signals driven by software should not be used in the receiving domain’s logic without synchronization. Failure to do so will cause timing violations and result in metastability.
Do not combine signals after synchronization
The outputs of different synchronizers in the receiving domain cannot be combined and used elsewhere (Figure 7a) because there is no way to guarantee their synchronization order, so there is a chance of sampling the wrong data. If two signals must be combined for use in the receiving domain, then it is better to combine them in the sending domain (Figure 7b) or use some other means to overcome the coherency issue.
Figure 7 Re-converging synchronized signals in the receive domain can lead to design failure, so it is better to combine them before sending across the clock domains.
Following these guidelines when synchronizing signals crossing different clock domains will go a long way toward ensuring that metastability issues do not crop up in your multi-domain SoC and FPGA designs.
This article was originally published on EDN.
Deekshith Krishnegowda is a senior design engineer at Marvell Semiconductor, Santa Clara. He holds a master’s degree in Electrical & Electronics Engineering from San Jose State University and a bachelor’s in Electronics & Communication Engineering from Dayananda Sagar Institutions, Bangalore.
Related articles:
- Understanding Clock Domain Crossing Issues
- Synchronizer techniques for multi-clock domain SoCs & FPGAs
- Get those clock domains in sync
- Understanding the basics of setup and hold time
