cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
marode
Participant
Participant
1,747 Views
Registered: ‎04-27-2009

XPM_FIFO_AXIL and XPM_FIFO_AXIF independent clock mode missing reset cdc in code and CLOCKING_MODE allowed values

Jump to solution

This is related to the XPM_FIFO_AXIL and XPM_FIFO_AXIF macros on Vivado 2018.3.

The new Xilinx parameterized macros for AXI lite and full bus FIFOs have issues in independent clock mode:

  1. CLOCKING_MODE attribute is checked for "common"  and "independent" values, not for "dependent_clock" and "independent_clock" as stated in the documentation
  2. some resets to the XPM_FIFOs, used in the two macros are not synchronized to the write clock as required, hence, timing errors occur.

I will write my solution in the next post.

0 Kudos
1 Solution

Accepted Solutions
marode
Participant
Participant
1,742 Views
Registered: ‎04-27-2009

For the first issue you can either use "common" or "independent" for the CLOCKING_MODE or change definition of P_COMMON_CLOCK as below (also used in XPM_FIFO_AXIS)

localparam integer P_COMMON_CLOCK = ( (CLOCKING_MODE == "common_clock"      || CLOCKING_MODE == "COMMON_CLOCK"      || CLOCKING_MODE == "COMMON" || CLOCKING_MODE == "common") ? 1 :
                                    ( (CLOCKING_MODE == "independent_clock" || CLOCKING_MODE == "INDEPENDENT_CLOCK" || CLOCKING_MODE == "INDEPENDENT" || CLOCKING_MODE == "independent") ? 0 : 1));

 

the second issue can be resolved by inserting a reset synchronizer for the reset of the fifos where the write clock is "m_aclk_int", i.e. xpm_fifo_base_wrch_dut and xpm_fifo_base_rdch_dut

wire     rst_axil_m_aclk_int;

if (P_COMMON_CLOCK == 0) begin : gaxil_rst_sync
	xpm_cdc_sync_rst #(
		.DEST_SYNC_FF   (CDC_SYNC_STAGES),
		.INIT           (0),
		.INIT_SYNC_FF   (1),
		.SIM_ASSERT_CHK (0)
	) xpm_cdc_sync_rst_inst (
		.src_rst  (~s_aresetn),
		.dest_clk (m_aclk_int),
		.dest_rst (rst_axil_m_aclk_int)
	);
end // gaxil_rst_sync
if (P_COMMON_CLOCK == 1) begin : gaxil_rst
	assign rst_axil_m_aclk_int = ~s_aresetn;
end // gaxil_rst

use the new synchronized reset signal in xpm_fifo_base_rdch_dut and xpm_fifo_base_wrch_dut 

xpm_fifo_base_wrch_dut (
        .sleep            (1'b0),
        .rst              (rst_axil_m_aclk_int),
        .wr_clk           (m_aclk_int),
....


This has to be done for both XPM_FIFO_AXIL and XPM_FIFO_AXIF.
The code of the XPM macros can be found under Xilinx\Vivado\2018.3\data\ip\xpm\xpm_fifo\hdl and I edited the code there directly.
However, I am not sure if that is the right procedure.

View solution in original post

0 Kudos
8 Replies
marode
Participant
Participant
1,743 Views
Registered: ‎04-27-2009

For the first issue you can either use "common" or "independent" for the CLOCKING_MODE or change definition of P_COMMON_CLOCK as below (also used in XPM_FIFO_AXIS)

localparam integer P_COMMON_CLOCK = ( (CLOCKING_MODE == "common_clock"      || CLOCKING_MODE == "COMMON_CLOCK"      || CLOCKING_MODE == "COMMON" || CLOCKING_MODE == "common") ? 1 :
                                    ( (CLOCKING_MODE == "independent_clock" || CLOCKING_MODE == "INDEPENDENT_CLOCK" || CLOCKING_MODE == "INDEPENDENT" || CLOCKING_MODE == "independent") ? 0 : 1));

 

the second issue can be resolved by inserting a reset synchronizer for the reset of the fifos where the write clock is "m_aclk_int", i.e. xpm_fifo_base_wrch_dut and xpm_fifo_base_rdch_dut

wire     rst_axil_m_aclk_int;

if (P_COMMON_CLOCK == 0) begin : gaxil_rst_sync
	xpm_cdc_sync_rst #(
		.DEST_SYNC_FF   (CDC_SYNC_STAGES),
		.INIT           (0),
		.INIT_SYNC_FF   (1),
		.SIM_ASSERT_CHK (0)
	) xpm_cdc_sync_rst_inst (
		.src_rst  (~s_aresetn),
		.dest_clk (m_aclk_int),
		.dest_rst (rst_axil_m_aclk_int)
	);
end // gaxil_rst_sync
if (P_COMMON_CLOCK == 1) begin : gaxil_rst
	assign rst_axil_m_aclk_int = ~s_aresetn;
end // gaxil_rst

use the new synchronized reset signal in xpm_fifo_base_rdch_dut and xpm_fifo_base_wrch_dut 

xpm_fifo_base_wrch_dut (
        .sleep            (1'b0),
        .rst              (rst_axil_m_aclk_int),
        .wr_clk           (m_aclk_int),
....


This has to be done for both XPM_FIFO_AXIL and XPM_FIFO_AXIF.
The code of the XPM macros can be found under Xilinx\Vivado\2018.3\data\ip\xpm\xpm_fifo\hdl and I edited the code there directly.
However, I am not sure if that is the right procedure.

View solution in original post

0 Kudos
marode
Participant
Participant
1,585 Views
Registered: ‎04-27-2009

No other suggestions from Xilinx, so I mark my own answer as the solution.

0 Kudos
marode
Participant
Participant
1,087 Views
Registered: ‎04-27-2009

now we have Vivado 2019.2. The issue with the CLOCKING_MODE values is fixed.

However, the cross clock domain issue is not solved yet, in my opinion. Am I the only one having issues with that? Or am I the issue?

The fixes I proposed in the post above, do work, but are fixes in the wrong place. There is a reset synchronizer in xpm_fifo_base (xpm_fifo_rst) already. However, to me it seems the powerup reset and the rst_i signal create a inter-clock path which is not correctly handled. 

 

0 Kudos
marode
Participant
Participant
1,048 Views
Registered: ‎04-27-2009

So I tried to fix the xpm_fifo.sv code to handle independent clock mode, without getting inter-clock domain issues.

I added another cdc reset synchronizer to the xpm_fifo_rst instance, which fixes one issue. But there is another inter-clock domain path. This is were I gave up.

So in the end the solution above is still the way to go, at least for me. 

It would be nice, if one could talk to the people at Xilinx which actually wrote to code. 

 

0 Kudos
pthakare
Moderator
Moderator
1,037 Views
Registered: ‎08-08-2017

Hi @marode 

This is already reported to developement team and  proposed to fixed in VIVADO 2020.1 . They have provided the patch for 2019.1, we will verify the patch at our end and send you shortly.

 

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------
0 Kudos
marode
Participant
Participant
1,000 Views
Registered: ‎04-27-2009

Hi @pthakare 

perfect, thank you very much for the information. I started to feel very alone with this issue.

And changing stuff in the Vivado installation directory always seems like a bad hack.

0 Kudos
alexis_jp
Explorer
Explorer
237 Views
Registered: ‎09-10-2019

It seems it's still present in 2020.1 ...

0 Kudos
alexis_jp
Explorer
Explorer
197 Views
Registered: ‎09-10-2019

And still not solved in 2020.2.

0 Kudos