Zynq - Configuring SPI clock to idle high

Question

I am trying to use the SPI0 component of a Zynq XC7Z010 to read data from a 12-bit rotary encoder which uses an SSI protocol.

• I have a small example project set up in Vivado which enables the SPI0 to use EMIO ports and sets the pins I want to use.
• I also have the xspips driver working and am able to receive data from the encoder.

• The problem I am facing is that I could only set up a clock signal which is idle low, while the encoder expects an idle high clock.

  • Due to this, the first bits received are unusable, and I had to do some bit-manipulation to recover these bits (the encoder starts repeating the same data again after the 12 bit transmission).

With an oscilloscope I tested out that the sent out clock signal is always idle low, whether the CLK_ACTIVE_LOW option is set or not for the SPI, so I concluded that that option is only for how the Zynq interprets the clock signal.

How can I have a clock signal that is high by default? Do I have to manually invert it in the Vivado generated VHDL wrapper, or is there a simpler solution?

Measured clock signal for a 2 byte transfer when ACTIVE_LOW is enabled: and when it is disabled:

Answer 1

Your first oscilloscope trace (ACTIVE_LOW enabled) seems to show the clock going high-Z when idle. Note the slow decay. Try adding a fairly week pull-up resistor to the clock line, maybe 10K, and I think you'll ge what you want.

Answer 2

If you're having lost bits due to your clock xource being active-high when you need an active-low clock source, the logical answer would seem to be to add an inverter inline between your clock source & the clocked device that needs the inverse clocking waveform.

Try using something like this. It should work for a drop-in fix ;)

Answer 3

I also had some trouble with the Zynq SPI peripheral and as DoxyLover pointed out it has to do with the clock line being set to High-Z in Linux when data isn't being transferred. I solved this by bringing out the tristate pins for the clock line and manually feeding them into an IOBUF in my HDL, where instead of using the ZYNQ SPI tristate line I tied it low so the clock is always an output (actively driven).

Answer 4

I believe the tri-state answer is key here. Sending SPI to EMIO exposes a lot of signals, most of which aren't needed in a given application. This includes tristate signals for just about everything. This is for two reasons. First the SPI can be configured as a master or a slave. Second it can be configured to work with multiple masters. Both of these require the IP to tri-state some signals when not in use.

To avoid tri-stating the clock, simply expand the signals and don't use the tri-state control lines.