[Idea]: add configurable FIFO to SPI core

[akaeba]

Hi Stephan,

at the moment i interface an SPI Flash via your SPI core. The interaction with the SPI flash produces high IRQ rates in the system. Very helpful would be to lower the IRQ rate by an FIFO to call the ISR once and send a couple of bytes more. In the Regs are bity beyond Bit16 free.

neorv32/rtl/core/neorv32_spi.vhd

Line 93 in ef929c8

constant ctrl_highspeed_c : natural := 16; -- r/w: spi high-speed mode enable (ignoring ctrl_prsc)

For example could be bit17 to bit19 used for a configurabale FIFO size. The default should be zero and therefore full backward compatible. Following Formula could implement the size SIZE = 2**FIFO-1.

FIFO	SIZE
0	0
1	1
2	3
3	7
7	127

For me would be a FIFO size of 16 to 32Bytes very suitable. What do you think? If you like i can try to prepare some commits.

BR,
Andreas

[stnolting]

Hey Andreas!

I really like the idea to add a FIFO to the SPI module.
I think the FIFO size should be static - just like the FIFOs in the other modules (like the UARTs). So we would add a new generic IO_SPI_FIFO to configure the FIFO size. If this generic is set to zero (default) we would basically have the current setup.

If we expose the FIFO status signals (empty, at least half full, full) via the SPI control register the software could either use these flags when using the FIFO or just the busy signal of the SPI PHY layer if the FIFO shall not be used.

Regarding the SPI interrupt: we could add further control register flags to configure the interrupt:

• fire IRQ when current SPI transfer is done
• fire IRQ if FIFO becomes less than half-full
• fire IRQ when FIFO becomes empty

Internally, we would need two FIFOs - one for TX data and another one for RX data. However, the handling would be transparent for the software.

But how to handle the CS lines? Should they also be controlled by the FIFO somehow? This would allow to "program" complete sequences and store them to the FIFO. The SPI will process them and then fires an interrupt... 🤔

[akaeba]

But how to handle the CS lines? Should they also be controlled by the FIFO somehow?

There I would prefer to keep is at it is. Because if you have only 32 bytes fifo for instance but you like to program a whole flash page with 256 bytes, then the flash will execute your command when CS goes high. Alternativ you can add one more config bit. Auto csn or so. But then you need also an SW override.

BR andreas

[stnolting]

Good point! So we leave CS control entirely to the software.

What do you think about the IRQ proposal? I think that should cover all relevant cases, right?

[akaeba]

What do you think about the IRQ proposal? I think that should cover all relevant cases, right?

Yes I think also that this covers all the relevant cases. For legacy compatibility should the default setting, fire on fifo empty.

[stnolting]

Great!

I think I'll experiment a little bit with the SPI module... I will do a PR if there is something ready to show 😉

[akaeba]

Hi Stephan,

I think I'll experiment a little bit with the SPI module... I will do a PR if there is something ready to show

Perfect. Thanks :)

Some more Thouhts:

• related to the width between 1 and 4 bytes of the spi core would be from implementation point of view 4x8bit Fifos the best choise. Then you can change only the pointer increment by 1/2/4 based on the SPI config. Then should the FIFO size scale in multiples of four SIZE = (2**FIFO-1)*4
• When you only implement the Empty IRQ then it would possible to use for RX/TX the same FIFO, cause you start with Push on value into the SFR, then is one position free in the FIFO, then you read the MISO data from the SFR back and can store it to the free FIFO position and so on.

BR,
Andreas

[akaeba]

but what about the other status flags? Are they required???

I don't think that you need an tx fifo full, because you know the size.

From sw point of view I'll use an variable to count the number of mosi bytes in the last cycle, and this builds the number of read bytes in the current cycle.

[stnolting]

Good point. Especially because the FIFO size can be read from the control register (there are 4 bits now that show log2 of the FIFO size). What about RX.full? I think this is also kinda useless, right?

[akaeba]

What about RX.full?

At the moment I try to imagine a configuration where it's useful. But I have no idea. I mean then you need two independent paths for read and write, and you have always to write bytes for clocking. In short no.

[stnolting]

I think all TX FIFO flags are quite helpful (if NOT using interrupts):

• tx_fifo.empty: if set you can put another FIFO_SIZE-sized data package into the buffer
• tx_fifo.half: if not set you can put another FIFO_SIZE/2-sized data package into the buffer
• tx_fifo.full: if not set you can put at least "one more" data word into the buffer

When it comes to the RX FIFO I think a single "rx_fifo.avail" (= not rx_fifo.empty) flag might be sufficient... 🤔

[akaeba]

D'accord :)

[stnolting]

I drafted a first version in #381. The software framework needs some updates and also the data sheet but the SPI module should be fully backwards compatible.

@akaeba It would be great if you could adapt the sw/example/demo_spi_irq example so we can test FIFO'S interrupt behavior. 😉

[akaeba]

Hi Stephan, yes I can adjust the example in the next days 😉

[stnolting]

Awesome! Thanks for your help!