cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rhickey
Contributor
Contributor
2,253 Views
Registered: ‎01-19-2016

[DRC REQP-1839] RAMB36 async clock control check on AXI data fifo

Hello,

I am getting 

[DRC REQP-1839] RAMB36 async control check: The RAMB36E1 .../DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram has an input control pin ... inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram/ENARDEN (net: ..._state_reg[0]) which is driven by a register (.../ram_full_i_reg) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

This is in a Xilinx IP block. The top level connections to this block -> aresetn comes from a proc system reset block, the aclock comes from a clk_wiz.

Do I safely ignore this warning or do I need to look at something else?

 

 

0 Kudos
5 Replies
pthakare
Moderator
Moderator
2,214 Views
Registered: ‎08-08-2017

Hi @rhickey

Please share your block design in entirety or bd_tcl file or Block design Snippet + AXI data fifo .xci file to reproduce this issue at our end.

---------------------------------------------------------------------------------------------------------

Reply if you have any queries, give Kudos and Accepts as Solution

---------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------
0 Kudos
rhickey
Contributor
Contributor
2,204 Views
Registered: ‎01-19-2016

I am unable to share this data.  Is there any advice that you could offer without having the design?

Thanks,

Roger

0 Kudos
ojos
Observer
Observer
1,840 Views
Registered: ‎07-27-2012

I have got the same warning from an IP synthesized and pakaged by Vivado HLS. I have used SystemC to describe the IP and all the clock thread used on the design have a synchronous reset. It seems the problem is in the Xilinx's BRAM description. I am using VHDL for RTL synthesis. Vivado version 2017.2.

@pthakareI attach the SystemC source files, so you may be able to reproduce the issue.

 

0 Kudos
ojos
Observer
Observer
1,829 Views
Registered: ‎07-27-2012

Sorry, there is a bug introduced by a colleague in the example design. On the AXISlave.cpp, when registering addresses (in both cthreads) the XOR (^) operation with the SYS_AXI_BASE produce wrong ressults. The easiest solution is to comment this lines and the preprocessor IFs, and left only the substraction (-) opperation with the SYS_AXI_BASE.
0 Kudos
cbhiskp
Adventurer
Adventurer
384 Views
Registered: ‎06-17-2015

I seem to have a similar problem, thus I will hijack this post instead of creating a new one.

If I follow the schematic, I find that empty_fwft_i_reg has an asynchronous PRESET input, which is connected to a reset signal. However, ultimately the reset signals are synchronous and originate in a FF from the same clock domain.

My design DOES suffer from very unclear problems that might be related to memory corruption. Now it is very hard for me to track this down, even more so since this is mostly from inside a Xilinx IP. At which point can I be sure that this is a false alarm?

Currently I am trying to find out if this can be tracked to a set_false_path that I have put on some reset signals - would this be a possible explanation, that is is in fact not asynchronous, but not timing analyzed?

 

 

 

[DRC REQP-1839] RAMB36 async control check: The RAMB36E1 TOP_inst/event_sender_inst/gen_fifo.axis_data_fifo_0_inst/inst/gen_fifo.xpm_fifo_axis_inst/xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst/gen_wr_a.gen_word_narrow.mem_reg_0_0 has an input control pin TOP_inst/event_sender_inst/gen_fifo.axis_data_fifo_0_inst/inst/gen_fifo.xpm_fifo_axis_inst/xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst/gen_wr_a.gen_word_narrow.mem_reg_0_0/ENARDEN (net: TOP_inst/event_sender_inst/gen_fifo.axis_data_fifo_0_inst/inst/gen_fifo.xpm_fifo_axis_inst/xpm_fifo_base_inst/gen_sdpram.xpm_memory_base_inst/wea[0]) which is driven by a register (TOP_inst/event_sender_inst/axis_arbitrate_inputs_inst/inst/axis_interconnect_0/inst_si_datapath[0].dynamic_datapath_si/gen_data_fifo.axis_data_fifo_0/gen_fifo_generator.fifo_generator_inst/inst_fifo_gen/gaxis_fifo.gaxisf.axisf/grf.rf/gntv_or_sync_fifo.gl0.rd/gr1.gr1_int.rfwft/empty_fwft_i_reg)
that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

 

 

 

0 Kudos