[solved] SPI - Xilinx XSpi core / ARM Linux board - is "too much phase delay"?

[TinkeringSteve]

Hey folks,

so I was handed an Xilinx FPGA board with the standard SPI core by Xilinx, which is handled by the Microblaze processor also in there, using the Xilinx-provided XSpi library. In particular, trying the SPI-slave-interrupt based example of theirs.
(I know of the existence of the Xilinx forum, which seems to be largely useless)

I'm coding for the Microblaze, and then the ARM Cortex A based Linux board as the master, where I'm using the standard linux "spidev" driver.

The master is clocking at 6 MHz, connected to the slave via ~ 20cm long loose wires, which are tapped to connect a logic analyzer.

The Microblaze slave does receive the data sent by the master correctly, e.g. sending 8x uint32's (it's set up for 32bit width at both ends) of 0x0badf00d, 0xc0cac01a and what have you.
So this would seem to mean to me that both ends' hardware is set up correctly, as clocks, polarities and such are set up for both directions, not independently.

But the data the slave sends gets *not* received correctly. It is mangled in a repeatable pattern.
E.g. the slave sends as 32bit numbers 0x50...0x57, the master receives this: {0x28, 0x28, 0x80000029, 0x29, 0x8000002a, 0x2a, 0x8000002b, 0x2b}, which looks like integer 1/2 of the expected values, plus the MSB sometimes set additionally.

Interestingly, the logic analyzer (sampling at 125MHz) also does not decode the MISO line, it shows hex/ascii only for MOSI line, but there are not separate settings, only one for what you want to display. So I guess it can't.


The MISO phase looks a bit delayed compared to the rest, but I don't know whether that's bad or not.

Any idea what might cause this?

-------------------------------
UPDATE:

Ok folks, it now works - the exp_spi_clk of the AXI Quad SPI core was set too low vs. the intended SPI speed. That was the only change made resulting in seeing the expected data on both ends.

[jeremy]

What does the MISO line look like on an oscilloscope? Logic analysers are great at hiding clues in problems like these 

You can also use the Xilinx ILA to tap the SPI lines inside the fabric to see if it is getting garbled before it exits the fpga.

[NorthGuy]

20-30 ns delay is not a problem for 6MHz SPI.

Looks like you're off by 1 bit. There are two things you can do.

1. You need some sort of method to synchronize your bytes, such as CS line. Otherwise, a single wrong clock will distort all the future communications.

2. You need to make sure you use correct SPI mode - that is both master and slave use the same mode. Right now, it appears your master launches data on falling edge (and consequently will sample at rising edge). Meanwhile, your slave launches data on rising edge.

[mikerj]

Definitely get a scope onto that MISO line, you'll probably find it has slow rise/fall times.  Is the drive strength of the MISO pin configurable on the Xilinx?

[TinkeringSteve]

Doesn't look too unusual an the scope to me:

The time that it reaches 1.8V or what the min "hi" threshold is, is reach faster than could explain the visible delay on the other diagram.

The thing is, I didn't see anything that suggests I can configure the polarities differently for MOSI vs. MISO.

-------------------
Ok folks, it now works, I'll edit the OP to explain.

[mikerj]

Doesn't look too unusual an the scope to me:

The time that it reaches 1.8V or what the min "hi" threshold is, is reach faster than could explain the visible delay on the other diagram.

The thing is, I didn't see anything that suggests I can configure the polarities differently for MOSI vs. MISO.

-------------------
Ok folks, it now works, I'll edit the OP to explain.

Did you compare it to the clock on the scope?  The input and output polarities are defined by the SPI mode, they are not independently configurable (at least not in any device I have used).