CDC-50001 - 1-Bit Asynchronous Transfer Not Synchronized

Hi,

I’ve tried multiple combinations of the set_instance_assignment command,
but nothing seems to work. Below are the commands I used in the TCL window of the Timing Analyzer tool.
After entering the commands, I clicked on Report DRC, but nothing changed.
I also tried clicking Reset Design, Update Timing Netlist, and finally Report DRC again, but still no changes.
Do I need to re-synthesize the design?

Here are the commands I tried:

set_instance_assignment -entity evt_dib_ip_i|die_ready_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED IF ASYNCHRONOUS"
set_instance_assignment -entity evt_dib_ip_i|die_ready_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED IF ASYNCHRONOee"
set_instance_assignment -entity evt_dib_ip_i|die_ready_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED"
set_instance_assignment -entity evt_dib_ip_i|die_ready_sync_i|sync1_in_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED IF ASYNCHRONOUS"
set_instance_assignment -entity evt_dib_ip_i|die_ready_sync_i|sync1_in_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED"
set_instance_assignment -to evt_dib_ip_i|die_ready_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED IF ASYNCHRONOUS"
set_instance_assignment -to evt_dib_ip_i|die_ready_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED"
set_instance_assignment -to evt_dib_ip_i|die_ready_sync_i|sync1_in_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED IF ASYNCHRONOUS"
set_instance_assignment -to evt_dib_ip_i|die_ready_sync_i|sync1_in_Z -name SYNCHRONIZER_IDENTIFICATION "FORCED"

Hi,

Could you provide .qar file for taking a look?

Thanks,

Regards,

Sheng

Hi,

After interchange the clock between die_ready_Z and sync1_in_Z, sync2_in (screenshots)

The remaining CDC-50001 warnings are cleared.

Based on CDC-50001 descriptions:

If you do not intend a violating transfer to be asynchronous, ensure that the launch clock of the transfer is correct and is related to the latch clock of the transfer

Thanks,

Regards,

Sheng

Bottom line:
I don’t understand the suggested solution.

The places you edited are synchronizers. As a synchronizer, the intention is to put one FF on the source clock domain and two FFs on the target clock domain, as it is in the original design (see the first picture below).
In the instance die_ready_Z, the first FF is on the clock domain of pll_clk and it is only one FF. The next two FFs are on the clock which arrives from the DIB dib_rx_data_2_18_in_i_0_0 (the target clock domain).
You will see that the Q (output) of sync2_in is going to FFs which use the same clock domain (dib_rx_data_2_18_in_i_0_0). I didn’t include this in the picture as it complicates the view.
I don’t understand the solution you described (see the second picture). You switched clocks? Why? This does not sync it to the target clock domain.
Bottom line: This thread is about recognizing synchronizers. I don’t understand from your solution why Quartus didn’t recognize these standard synchronizers and why I need to adopt your solution.

Or

Hi Or,

The problem found is not enough synchronizer. You may increase the synchronizer by using Parameterizable Macro (ipm_cdc_1clk_sync) check this link https://www.intel.com/content/www/us/en/docs/programmable/772350/24-2/synchronizer-using-single-clock-parameterizable-23701.html

Code changes screenshot:

Tech map viewer screenshot:

Code changes screenshot:

Tech map viewer screenshot:

Then the CDC-50001 warnings are disappeared.

Based on the future version 24.3 CDC-50001 description (screenshot below), Protect single-bit asynchronous data transfers by a synchronizer chain. Use the CDC parameterizable macros: Single Clock Parameterizable Macro (ipm_cdc_1clk_sync) or Two Clocks Parameterizable Macro (ipm_cdc_2clks_sync). ...To do this, ensure that the destination of an asynchronous transfer forms a chain of two or more registers,

Hi,

I’m having trouble understanding what’s wrong with my design. Are you suggesting that Quartus might have a bug?

I’ve already included 2 stages of flip-flops, and the synchronizer macro you added introduces 3 more stages.

So, do I need to synchronize with 5 flip-flops to eliminate the warning? Or is this a bug in the current version of Quartus?

Thanks,

Hi Or,

I have further identify that the root cause is the asynchronous reset prevents the synchronization of the flip-flop.

Asynchronous resets are sometimes avoided in synchronizer chains, as they can interfere with the metastability mitigation synchronizers provide. An asynchronous reset applied to a synchronizer can cause the register to enter a metastable state when the reset is deasserted, potentially propagating unreliable signals through the chain. So if the registers have an asynchronous reset, the tool sometime may not recognize the chain as a synchronizer.

For a reliable synchronizer, don't use asynchronous reset like below code changes (screenshot):

Then the CDC-50001 warning disappear.

Just left this warning (screenshot below):

This is clearly not enough flip-flops for synchronizer (screenshot below):

Thanks,

Regards,

Sheng

Hi Or,

I sent the screenshots to you though email.

Your answer looks reasonable, and I will try it with my design. I will also check the unsynchronized area you pointed out. I’ll update you in a few days.

Hi Or,

Sure. Let me know if you have any further concern or update.