Thanks for the link to the paper. It’s always good to get another perspective on how to design these circuits. I’ll add it to the reference section as well.

When synchronizing a signal, the first considerations must always be the relative frequencies of the two domains, and how frequently data needs to be transferred between them (the rate of synchronization). I think the paper you referenced mentions a two destination cycle limitation to ensure the output pulse is distinct and single cycle. Yes there is the same limitation in my MCP without feedback circuit because the output pulse is used to load the output flip-flop, and the source flip-flops cannot change until this occurs. So to use the MCP without feedback circuit you must be sure that the input data rate is fairly slow. If you are unsure or if the design requires more frequent synchronization, then the feedback synchronizer or asynchronous FIFO should be used.

As for the sentence from the article, I wonder if he meant the frequency of input clock is greater than twice the synchronizer clock. I don’t see why a long input pulse would be a problem for this toggle synchronizer.

As in https://i.stack.imgur.com/lXrCw.jpg extracted from https://inst.eecs.berkeley.edu/~cs150/sp10/Collections/Papers/ClockCrossing.pdf#page=3 , it seems to me that toggle synchronizer needs to impose that input pulses must have a minimum spacing between pulses equal to two synchronizer clock periods.

The article also mentioned “This problem is more severe when the clock period of input pulse is greater than twice the synchronizer clock period ”

Do you have any comments about this ?

Hi Promach. If you’re talking about the Multi-cycle path (MCP) formulation without feedback, it should work for sending both ones and zeros. There are two different paths through the synchronizer—1) the data path where the data to be synchronized is sent to the destination and can be either one or zero, 2) the synchronization event indication. In this design, the source logic must create a single cycle positive pulse to indicate there is data on the data path to synchronize.

Besides, http://www.verilogpro.com/clock-domain-crossing-part-3/ returns 404 status

Hi Pan. Yes you’re right! My code didn’t match the diagram I drew, and was inserting an unnecessary extra cycle before the data appeared on the destination side. I’ve fixed the code and waveform. Thanks for pointing that out!

But I noticed a discrepancy in the SystemVerilog code, in the sync_mcp_sedt, you made the “data_valid_sync <= ldtoggle_sync ^ ldtoggle_sync_d1“ excute under the dest_clk, shouldn't it be combinational?

But I noticed a discrepancy in the SystemVerilog code, in the sync_mcp_src, you made the “src2dest_ldtoggle <= src2dest_ldtoggle ^ src_data_valid“ excute under the dest_clk, shouldn't it be combinational?

And the waveforms of the above code shows a clk delay comparing to the waveforms in your post