cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
egrigor
Contributor
Contributor
1,366 Views
Registered: ‎12-11-2007

XPM_FIFO_AXIS Packet mode not working

Hi, I' m trying to use the XPM_FIFO_AXIS in packet mode and the simulation shows that it is misbehaving and non-functional.  There seems to be at least 2 bugs with this core.  I'm uisng Questa Sim-64 2019.2 with Vivado compiled libraries using Vivado 2019.2.  There was an earlier related bug reported in this Forum which I'm not sure if Xilinx ever fixed it, but regardless I'm still seeing issues with this core (see here:  https://forums.xilinx.com/t5/Xilinx-IP-Catalog/XPM-FIFO-AXIS-Packet-mode-not-working/m-p/853715#M4046).  Having reviewed earlier comments with regards to the XPM FIFOs, I made sure that I am applying resets correctly.  I have a reset synchronizer that applies an synchronous reset of duration 10 clocks. 

I have created a SytemVerilog(SV) wrapper for the XPM_FIFO_AXIS and have a SV test bench that writes 625 bytes to the slave side.  The parameters configure the FIFO to 4096 depth by 8-bit words.  I'm using it in "common_clock", "no_ecc", and PACKET_FIFO="true" with USE_ADV_FEATURES="1E0E" to enable write & read programmable, almost flags and data counts.  The slave tstrb and tkeep are tied to all ones ('1 in SV) as I'm not using these signals externally, so they are asserted to the core.  Then I have a State machine that waits for the FIFO programmable full flag which is set to 625 bytes to go high before it reads out the contents of the FIFO (an AXI-Stream packet which is terminated with tlast).  The writes to the FIFO appear to work, since the programmable full flag goes high right after 625 bytes are written to the FIFO, however, the master-side tvalid never goes high.  Figure 11 in UG974 (v2019.1, page 92) shows that m_axis_tvalid gets asserted 2 clocks after a word is written the slave side (s_axis_tvalid and s_axis_tready high simultaneously).  So the read-side (or the master-side) tvalid is not acknowledging any presence of data in the FIFO eventhough the programmble full appears to work fine.

ALSO, I'm doing a write to the FIFO on every clock for 625 clocks, however the wr_data_count_axis and rd_data_count_axis (named as o_wcount and o_rcount in my wrapper file, respectively) show half as many words stored in the FIFO (in conflict with the reported programmable flag).  From the waveforms, it can be seen that these counts are updating on every TWO s_aclk pos-edges instead of incrementing on every s_aclk pos-edge.  SO the counts being wrong is the second bug associated with this core.

Tags (3)
XPM_FIFO_AXIS_Write_Read_Fail1.png
XPM_FIFO_AXIS_Write_Read_Fail2.png
XPM_FIFO_AXIS_Write_Read_Fail3.png
0 Kudos
5 Replies
pthakare
Moderator
Moderator
1,342 Views
Registered: ‎08-08-2017

Hi @egrigor 

Looking at the simulation captures , it seems you are using 12 bits for write and read data counts  for 4096 depths .   It should be 13.

Check the WRITE_DATA_COUNT_WIDTH and READ_DATA_COUNT_WIDTH parameter description in XPM_FIFO_AXIS section in user guide below

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug974-vivado-ultrascale-libraries.pdf

 

Capture.PNG

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------
egrigor
Contributor
Contributor
1,304 Views
Registered: ‎12-11-2007

Yes, thank you for pointing the need for that extra bit.  I had not noticed the need for that extra bit in the user guide.  I increased the widths in my wrapper file's parameter calculations by 1 bit and the counters now correctly update:

localparam WR_COUNT_WIDTH = $clog2(FIFO_DEPTH)+1; 
localparam RD_COUNT_WIDTH = $clog2(FIFO_DEPTH)+1;

This solves only half of the problem, however I still don't see tvalid get asserted on the master side, which is supposed to happen as soon as the FIFO has any data in it.  Also, if there is no read activity, as evidenced by no transitions on tvalid and tdata, then the read count should not be incrementing either, so that's also inconsistent. 

XPM_FIFO_AXIS_Read_Fail1.png
0 Kudos
dmsspb
Contributor
Contributor
1,080 Views
Registered: ‎01-13-2020

Same problem. XPM_FIFO_AXIS packet mode PACKET_FIFO="true" doesn't work in vivado 2019.2. No tvalid signal. When PACKET_FIFO="false" tvalid signal is correctly asserted.

UPD. Use Vivado 2019.2 IP Core "AXI4-Stream Data FIFO" instead. It uses the same xpm_fifo_axis but packet mode and independent clock mode works.

xpm_fifo_axis alone work fine in common clock and no packet mode.

jrwagz
Participant
Participant
609 Views
Registered: ‎02-12-2020

I can confirm that XPM_FIFO_AXIS is still broken in 2020.2.  It's a shame that we have to generate an IP, and that we can't just reference the XPM in our own RTL.  These two things should be interchangeable! 

0 Kudos
shantmoses
Contributor
Contributor
299 Views
Registered: ‎07-01-2008

The workaround is to hold the initial FIFO reset asserted for more than 100ns (long enough for glbl.GSR to deassert) then deasssert the FIFO reset.

This is needed in /opt/Xilinx/Vivado/2020.2/data/ip/xpm/xpm_fifo/hdl/xpm_fifo.sv to generate rst_axis to properly reset axis_pkt_cnt. The latter is used to generate axis_pkt_read after receiving a packet which in turn is used to generate m_axis_tvalid.

Regards,

Shant

0 Kudos