Possible SLINK RX FIFO overflow

[robhancocksed]

Describe the bug
I am using the SLINK interface to feed data into the NEORV32 from a Xilinx AXI DMA core. The SLINK RX FIFO size is set to 16 currently. There are some cases where I end up feeding a large amount of data into the RX, faster than the CPU can consume it, so the TREADY flow control is needed to avoid the RX FIFO from overflowing.

I have observed that on the first chunk of data going into the CPU (where initially words are accepted on every clock cycle until the FIFO fills up), one word appears to be lost in the data read out on the CPU, whereas later on (when the CPU is eating into the buffered data one word at a time) no further words are lost.

Looking at an ILA debug trace of the first chunk of data going into the core on the AXI stream, it appears that it accepts 17 words of data before de-asserting TREADY, which suggests that one word of data is discarded without making it into the FIFO. (I am pretty sure, though I guess not 100% certain, that no words were consumed from the FIFO yet during this time, due to the typically observed interrupt latency.) Later on, when words of data are consumed from the FIFO periodically, TREADY is only asserted for one cycle at a time as expected.

I am not sure if there could be a bug in the SLINK code or in the actual FIFO itself? Possibly something with the FIFO full signal being delayed one cycle and causing problems when writing with 100% duty cycle, but yet somehow it works when reading data from the FIFO a word at a time?

Hardware:

• Hardware version: Git commit af0633d from Feb.20, with fix applied for Duplicate driver for s1_axis_tvalid_int in neorv32_SystemTop_axi4lite.vhd #823
• Using top-level AXI Lite instantiation
• Extensions A, B, C, M, Zicntr enabled, fast multiply, fast shift
• GPTMR, MTIME, TRNG, UART0, WDT, on-chip debug, XIRQ, SLINK enabled
• Building with AMD Vivado 2023.2 for a Kintex-7 FPGA

[stnolting]

I think you are right. The SLINK FIFOs use "synchronous" reads so the FIFO status flags are delayed by one cycle to be sync with the actual (read) data. Hence, the FIFO full flag (or the according AXI stream "ready" signal) is updated one cycle too late. In case of the SLINK RX link the stream source issues another write as tready has not cleared yet which causes a data loss.

The simplest fix would be turning on asynchronous reads for the FIFOs. However, with the current FIFO logic style this would make Vivado infer distributed RAM instead of block RAM.

neorv32/rtl/core/neorv32_slink.vhd

Line 219 in 53930a6

FIFO_RSYNC => true, -- sync read

Do you think this might be okay-ish? I mean, you could use a small SLINK FIFO configuration and attach larger external block-RAM-based FIFOs (Vivado IPs). This would also allow to use dual-clock FIFOs partly solving #825. 🤔

[stnolting]

I think I've found a way to infer blockRAM even for "async read" configurations (-> #828):

https://github.com/AngeloJacobo/FPGA_Asynchronous_FIFO/blob/623266183329038c940ffeabc8352d38b712604c/src/asyn_fifo.v#L163-L166 by @AngeloJacobo

Vivado synthesis results look promising 🤞

[robhancocksed]

I confirmed this is fixed now, the RX FIFO now only accepts the correct number of words before TREADY is deasserted.