Design a 2-phase REQ-ACK CDC handshake sender and receiver module

Assuming sender block uses clk1, while receiving block uses clk2. Sender block and receiving block use 2-phase REQ-ACK protocol for clock domain crossing.

Also assume the sender block interacts with its upstream logic using valid-ready protocol, and the receiving block interacts with its downstream logic using valid-ready protocol.

We mentioned in previous post that, 2-phase REQ-ACK protocol is faster than 4-phase, but it is also less robust compared to 4-phase.

In 2-phase REQ-ACK protocol, if only transmitting side goes to reset, REQ may have an unwanted toggle from 1 to 0. From receiving side’s perspective, this is considered as a valid data transfer, but data captured by receiving side may be unknown. This can cause metastability issue in receiving side.

 

Design a 4-phase REQ-ACK CDC handshake sender and receiver module

Assuming sender block uses clk1, while receiving block uses clk2. Sender block and receiving block use 4-phase REQ-ACK protocol for clock domain crossing.

Also assume the sender block interacts with its upstream logic using valid-ready protocol, and the receiving block interacts with its downstream logic using valid-ready protocol.

Obviously, 4-phase REQ-ACK protocol is slower than 2-phase REQ-ACK protocol, since each transfer involves 4 signal transitions compared to 2 signal transitions.

However, 4-phase REQ-ACK protocol is more robust than 2-phase REQ-ACK protocol. We will explain the reason in next post.

 

What are common CDC considerations to transfer a pulse and to transfer multi-bit signals?

CDC considerations to transfer a pulse

Transfer a pulse from slow to fast clock domain, and from fast to slow clock domain, require separate handling.

Generally speaking, passing a signal from slow clock to fast clock is not a problem, since the loss of a pulse is less likely to happen. Based on Nyquist Theorem, if receiving clock frequency is at least 2x of sending clock frequency, then there will be no sampling loss.

Continue reading → What are common CDC considerations to transfer a pulse and to transfer multi-bit signals?

What is MTBF? Why can synchronizers handle CDC?

What is MTBF?

For most applications, it is important to calculate the Mean Time Before Failure / MTBF for any signal crossing a CDC boundary. In the context of MTBF, the failure means the output of the synchronizer still goes metastable. Obviously, a larger MTBF is favored over a smaller one, and the synchronization scheme needs to guarantee sufficient larger MTBF.

MTBF is inversely proportional to input data changing rate as well as receiving clock frequency. The faster of input data rate and receiving clock, the lower of MTBF.

Interviewees often mix the concept of input data changing rate with sending clock frequency, and incorrectly think sending clock frequency does impact MTBF. Faster sending clock does not necessarily imply faster input data changing rate.

It is required to flop the data in sending clock domain before synchronized in receiving clock domain. The output of combo logic often have glitches, i.e., it requires some time to settle. Without data flopping, the input data changing rate is effectively increased in receiving clock domain, decreasing the MTBF of CDC circuit.

Why can synchronizers handle CDC?

The simplest synchronization scheme is back-to-back flop synchronizer. Even though the output of the first stage is metastable, the CDC signal still have one more cycle to settle to a stable logic value. Therefore, synchronizers essentially increase the MTBF.

Conclusion

We recommend interviewees to further read Clifford E. Cummings’ paper “Clock Domain Crossing (CDC) Design & Verification Techniques Using SystemVerilog”.

How to specify SGDC / CDC constraints?

Before running Spyglass CDC flow, we need to provide some inputs to Spyglass. One of the most important inputs is SGDC constraints. Usually, in SGDC constraints, designers are required to specify:

  1. Current design, to limit the scope of CDC check
  2. List of source clocks and generated clocks
  3. List of valid abstract port / input constraints. Designers can derive these constraints from SDC such as “set_input_delay
  4. List of valid output constraints. Designers can derive these constraints from SDC such as “set_output_delay
  5. List of valid clock groups constraints. Designers can derive these constraints from SDC such as “set_clock_group”. Unlike STA, CDC flow by default assumes all clocks are asynchronous to each other, and it will attempt perform CDC check against all clock pairs. Designers shall use “set_clock_groups” to specify which clock pair is synchronous, thus CDC check is not required for such clock pair.

Continue reading → How to specify SGDC / CDC constraints?

What is metastability?

Metastability happens when a register / FF has a setup or hold time violation. When setup time or hold time violation occurs, the output of that register becomes metastable, i.e., entering a quasi-static state which settles to either low or high.

Design engineer needs to handle properly:

  1. For synchronous paths, all timing paths should be checked for setup time and hold time constraints. Designers rely on STA to perform a thorough check against all timing paths.
  2. For asynchronous paths, designers should implement proper synchronization for clock domain crossing / CDC. Proper synchronizations between clock domains make sure metastability does not occur, otherwise chip failure can happen. Designers rely on CDC check to make sure synchronization are properly implemented