Link Copied
In addition to my previous message, I have investigated the two warnings. The first warning pertains to an internal transfer within the memory of the synchronous FIFO, which I can disregard. The second warning is related to an issue similar to what was resolved by the “Forced if asynchronous” solution; however, this instance remains unresolved. As shown in the attached picture, there is a synchronization of 2 bits, as discussed in the original thread, but it is not being ignored this time. Could you provide any insights into why this might be happening?
+---------------------------+---------------------------------------------------+-------------------+-------------------+-----------------------+--------+
; CDC-50001 - 1-Bit Asynchronous Transfer Not Synchronized ;
+---------------------------+---------------------------------------------------+-------------------+-------------------+-----------------------+--------+
; From ; To ; From Clock ; To Clock ; Reason ; Waived ;
+---------------------------+---------------------------------------------------+-------------------+-------------------+-----------------------+--------+
+-------------------------------------------------------------------------------------------------------------------------------------------------------
; evt_dib_ip_i|die_ready_Z ; evt_dib_ip_i|die_ready_sync_i|sync1_in_Z ; pll_clk ; rx_clk (INVERTED) ; Asynchronous transfer ; ;
+---------------------------+---------------------------------------------------+-------------------+-------------------+-----------------------+--------+
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,
