11-20-2019 01:41 PM - edited 11-20-2019 02:19 PM
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.
11-20-2019 08:24 PM
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
11-21-2019 10:12 AM - edited 11-21-2019 11:13 AM
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.