SPI slave connected to ARM

[suppamax]

Hi,

I am building a microcontroller based on Ariane and I am reusing a lot of the peripheral I was able to find here. I implemented the system on FPGA (zcu102 board) and I connected the RISCV-based SoC to the ARM via SPI (ARM->AXI2SPI->SPI_slave).

My devicetree looks like this ` amba_pl: amba_pl@0 {

address-cells = <2>;

    #size-cells = <2>;
    compatible = "simple-bus";
    ranges ;
    axi_quad_spi_0: axi_quad_spi@a0000000 {
        bits-per-word = <8>;
        compatible = "xlnx,xps-spi-2.00.a";
        fifo-size = <16>;
        interrupt-names = "ip2intc_irpt";
        interrupt-parent = <&gic>;
        interrupts = <0 89 1>;
        num-cs = <0x1>;
        reg = <0x0 0xa0000000 0x0 0x800000>;
        xlnx,num-ss-bits = <0x1>;
        xlnx,spi-mode = <0>;
        spidev@0 {
            compatible = "spidev";
            reg = <0>;
            spi-max-frequency = <3125000>;
        };
    };

` I can see the spi peripheral. The problem is that it seems like the read accesses are affected by a bit shift (which changes with time). For example, if I read a memory section filled with "0x30" what I get is 0C 0C 0C 0C 06 06 06 06 03 03 03 03 01 81 81 81 80 C0 C0 C0 C0 60 60 60 60 30 30 30 30 18 18 18 18 0C 0C 0C 0C 06 06 06 06 03 03 03 03 01 81 81 81 80 C0 C0 C0 C0 60 60 60 60 30

Looking at your spiload application, it seems like you had a similar issue int spi_load(uint32_t addr, char* in_buf, size_t in_size) { //... // shift everything by one bit for(i = 0; i < transfer.len-1; i++) { rd_buf[i] = (rd_buf[i] << 1) | ((rd_buf[i+1] & 0x80) >> 7); } for(i = 0; i < in_size; i++) { if (in_buf[i] != rd_buf[i + 9]) { printf("Read check failed at idx %d: Expected %02X, got %02X\n", i, in_buf[i], rd_buf[i + 9]); } } //... Do you know the reason for this behavior?

[kdp1965]

Hi suppamax,

The SPI_slave module in the RI5CY seems to have a bug in the single wire SPI mode. We taped out and tested a 14nm chip with the RI5CY core and SPI_slave, and we have this same 1-bit shift issue that we had to work around in software. I haven't looked at detailed simulation waveforms to determine exactly what is causing this in the Verilog code, but certainly is was an issue for us until we figured out that we needed to shift the data.

I believe all of our pre-tapeout simulations used QSPI mode where this behavior wasn't present, so it appears to be a SPI only phenomonon.

Ken VP of Engineering, IQ-Analog Corp.

[newyt117]

hello, could anybody tell me what mode the pulpino spi use？ thanks！