0
\$\begingroup\$

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: enter image description here and when it is disabled: enter image description here

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I tried adding a 10K pullup, but in 'idle' state the clock line was still only 1.6V and I have the same problem with the lost initial bits as before. I don't think it would be safe to decrease the pullup by much, could there be any other way to get the line to 3.3V when idle? \$\endgroup\$ – Tusike Mar 2 '16 at 10:10
  • \$\begingroup\$ You tried this with ACTIVE_LOW enabled, correct? \$\endgroup\$ – DoxyLover Mar 2 '16 at 11:54
  • \$\begingroup\$ Yes, I have. But today I found something interesting; if I set up an 'AXI Quad SPI' IP block as a standard SPI, with the physical configuration exactly as before, then the ACTIVE_LOW option actually works and if I enable it, the clock remains idle high. Without any pullups. I do not get this behavior with the SPI module the Zynq IP block has. I guess I'll just use the Quad SPI block... \$\endgroup\$ – Tusike Mar 3 '16 at 16:21
0
\$\begingroup\$

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 ;)

\$\endgroup\$
  • \$\begingroup\$ Indeed, this will be my backup plan. If possible, I'd want a solution in which no extra hardware is required (or equivalently, I don't have to manually invert the port mappings in the FPGA code). \$\endgroup\$ – Tusike Mar 2 '16 at 10:00
0
\$\begingroup\$

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).

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.