ice40 SPI hardware cores on neorv32

[agamez]

Hi!

This is probably a non neorv32 issue but an ice40 one, but anyway, maybe some one has tried the same as I do and have some ideas.

I'm trying to use the "SPI hardened IP" of the ice40up5k of the iCEBreaker board although this discussion here doesn't really recommend using these cores, I want to have 2 SPI different cores, and I figured why not, let's save some LUTs.

I believe I have attached correctly the SB_SPI module to the wishbone interface, and I'm using the bus_explorer example application to try and communicate with the core. However, it doesn't really seem like it's properly happening. Since the SB_SPI module is 8 bits in both buses (data and address) I just tied them to the neorv32 wishbone interface like this. That's convenient because I can then use a non associated address such as 0x9A00000* to access this region.

                SBSTBI => wb_cyc, -- SB_SPI doesn't have a CYC signal. I also tried attaching SBSTBI => wc_stb with the same results
                SBADRI => wb_adr(7 downto 0),
                SBDATI => wb_dat_i(7 downto 0),

So I try to access the SB_SPI registers described in page 34 but I get some strange behaviour: traps due to timeout error (or the CPU stalls if I set WB bus timeout to infinite).

The first 6 reads are expected to fail because the first address on the PDF is 0111, but I would expect the rest of them to work fine. Only addresses 08, 0a and 0c seem to return anything. Is this a core problem or maybe I did something wrong regarding wishbone connectivity?

<<< NEORV32 Bus Explorer >>>

This program allows to read/write/dump memory space by hand.
Type 'help' to see the help menu.

BUS_EXPLORER:> setup
Select data size (press 'x' to abort):
 'b' - byte, 8-bit, unsigned
 'h' - half-word, 16-bit, unsigned
 'w' - word, 32-bit, unsigned
selection: b
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000000
[0x9a000000] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000000 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000001
[0x9a000001] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000001 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000002
[0x9a000002] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000002 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000003
[0x9a000003] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000003 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000004
[0x9a000004] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000004 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000005
[0x9a000005] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000005 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000006
[0x9a000006] => 0x00
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000007
[0x9a000007] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000007 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000008
[0x9a000008] => 0x00
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A000009
[0x9a000009] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A000009 </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000a
[0x9a00000a] => 0x00
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000b
[0x9a00000b] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A00000B </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000c
[0x9a00000c] => 0x50
BUS_EXPLORER:> write
Enter address (8 hex chars): 0x9A00000c
Enter data (2 hex chars): 0x60
[0x9a00000c] <= 0x60
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000c
[0x9a00000c] => 0x50
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000d
[0x9a00000d] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A00000D </RTE>
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000e
[0x9a00000e] => 0x00
BUS_EXPLORER:> read
Enter address (8 hex chars): 0x9A00000f
[0x9a00000f] => <RTE> Load access fault [TIMEOUT_ERR] @ PC=0x00000578, ADDR=0x9A00000F </RTE>

[NikLeberg]

Hi there @agamez

Sadly only connecting the adr and data lines of the wishbone bus is not enough. At least the additional control lines stb and ack must be connected. Simply put, the strobe or stb signal notifies the slave (your SPI module) of the start of a bus transaction and the acknowledge or ack signal tells the master (the neorv32 CPU) that the slave received the transaction. The TIMEOUT_ERR is generated by the neorv buskeeper and means that the CPU never got an ack from the slave.

See Figure 12 here for the complete timing diagram of a wishbone write access, disregard the tag signals.

So for your case, you may connect stb to SBSTBI and then search for an ack signal on the SPI module. If there is no acknowledge signals available there may be others like busy, done or ready that can be used with some simple conversion logic.
For testing purposes you may also try to connect stb directly to ack. This way (depending on the SPI complexity) at least the write accesses should work.

Cheers,
Nik

[agamez]

Oh, sorry, I didn't post the full connectivity, I just focused on the stb signal because the CYC/STB signals seem to be interchangeable as per YosysHQ/icestorm#174

I do have connected the ACK signal too to the bus:

        sb_spi : SB_SPI_WRAPPER
        GENERIC MAP (
                BUS_ADDR74 => "0b0000"
        )
        PORT MAP (
                SBCLKI => pll_clk,
                SBRWI => wb_we,
                SBSTBI => wb_cyc,
                SBADRI => wb_adr(7 downto 0),
                SBDATI => wb_dat_mosi(7 downto 0),

                MI => hard_spi_miso,

                SBDATO => wb_dat_miso(7 downto 0),
                SBACKO => wb_ack,
                SPIIRQ => open,
                SPIWKUP => open,

                MO => hard_spi_mosi,
                SCKO => hard_spi_sck,
                MCSNO => hard_spi_csn,

                SI => hard_spi_mosi,
                SCKI => hard_spi_sck,
                SCSNI => '0'
        );

[NikLeberg]

Thats correct, for single cycle bus transfers cyc and stb are almost identical. Although the cyc is meant for arbitration logic in the case there are multiple masters on the bus. So slaves should generally only use stb.

I've looked at the Ice40 datasheet for the hard SPI IP and could not find an ack equivalent signal. Maybe you need to dig into the documentation of the SystemBus they are referring to.

Have you tried connecting ack <= stb (while still connecting SBSTBI <= stb)?

[agamez]

ACK signal out of the hard SPI core should be simply SBACKO. I'll try attaching ack to stb just so it returns "something", but my guess is that the data I expect simply won't be there... Unless the IP core doesn't follow proper wishbone specification, which I guess is a possibility.

[stnolting]

I have never worked with the hard macros yet. But it seems like those controllers need a lot of configuration data before they can be actually used. There is a system design overview in the user guide that includes a 256x9-bit configuration ROM + FSM 🤔

I'll have a closer look at the documentation (as I am also planning to use these hard macros).