Long distance signalling...

[Piotr Wyderski]

Hi,

I have five upstream and one downstream signals that need to be passed
through an isolation barrier. The major part is SPI running at 10MHz;
the remaining signals are slower, but still in the MHz range. The device
will be connected with 2m of FTP CAT5e cable. Including the power
supply, there are just enough lines.

I am, however, concerned with the length of the shielded cable and I
would feel more comfortable with differential signalling. But just don\'t
have the wires. All the signals are fully synchronous, and there is an
FPGA on one end, mastering the communication, so fancy ideas are welcome.

My idea is to use the three pairs I have for a bidirectional LVDS
physical layer (say, TX, clock and RX) and re-build the SPI and the
remaining signals on top of that, already on the isolated end for
simplicity.

I was able to find some SERDES chips, but they are BIG. I don\'t need
28 input and 28 output lines or so. Do you know of something
significantly smaller?

Best regards, Piotr

 

[Ricketty C]

On Monday, August 17, 2020 at 4:37:10 AM UTC-4, Piotr Wyderski wrote:

Hi,

I have five upstream and one downstream signals that need to be passed
through an isolation barrier. The major part is SPI running at 10MHz;
the remaining signals are slower, but still in the MHz range. The device
will be connected with 2m of FTP CAT5e cable. Including the power
supply, there are just enough lines.

I am, however, concerned with the length of the shielded cable and I
would feel more comfortable with differential signalling. But just don\'t
have the wires. All the signals are fully synchronous, and there is an
FPGA on one end, mastering the communication, so fancy ideas are welcome.

My idea is to use the three pairs I have for a bidirectional LVDS
physical layer (say, TX, clock and RX) and re-build the SPI and the
remaining signals on top of that, already on the isolated end for
simplicity.

I was able to find some SERDES chips, but they are BIG. I don\'t need
28 input and 28 output lines or so. Do you know of something
significantly smaller?

Best regards, Piotr

You say you have an FPGA on one end, but what about the other end? How do you expect to combine the various signals to send to the FPGA?

Are your slower signals able to be transmitted by sampling asynchronously?

Small FPGAs are available for the transmitting end which would allow your SERDES to be constructed or there might be devices with SERDES built in. Lattice is big on small devices and tiny packages. I\'d do some digging for you, but I don\'t have time at the moment.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Michael Kellett]

On 17/08/2020 09:37, Piotr Wyderski wrote:

Hi,

I have five upstream and one downstream signals that need to be passed
through an isolation barrier. The major part is SPI running at 10MHz;
the remaining signals are slower, but still in the MHz range. The device
will be connected with 2m of FTP CAT5e cable. Including the power
supply, there are just enough lines.

I am, however, concerned with the length of the shielded cable and I
would feel more comfortable with differential signalling. But just don\'t
have the wires. All the signals are fully synchronous, and there is an
FPGA on one end, mastering the communication, so fancy ideas are welcome.

My idea is to use the three pairs I have for a bidirectional LVDS
physical layer (say, TX, clock and RX) and re-build the SPI and the
remaining signals on top of that, already on the isolated end for
simplicity.

I was able to find some SERDES chips, but they are BIG. I don\'t need
28 input and 28 output lines or so. Do you know of something
significantly smaller?

    Best regards, Piotr

Lattice MachX03 in 36 ball WLCSP (2.5mm square), 28 IO pins, the family
supports differential IO standards.

MK

 

[Piotr Wyderski]

Ricketty C wrote:

> You say you have an FPGA on one end, but what about the other end?

No constraints, except for relatively small size. By small I mean at
most the real estate of TQFP64. The part should have pins too, in the
worst case, QFN is acceptable.

> How do you expect to combine the various signals to send to the FPGA?

There are just 6 signals and 6 wires, so there is nothing inherently
needing combining. I am just concerned with the transmission integrity,
hence the idea of going differential.

> Are your slower signals able to be transmitted by sampling asynchronously?

By \"synchronous\" I meant that all the signals are synchronised to a
master clock the FPGA is providing. There is no need for asynchronous
sampling. Some signals are just slow but still synchronised.

> Small FPGAs are available for the transmitting end which would allow your SERDES to be constructed or there might be devices with SERDES built in.

Yes, this is an option too. I don\'t need a multi-gigabit SERDES,
anything a regular FPGA running at ~100MHz clock could do would be fine.
I just hoped that there is a small LVDS-capable 8-bit port expander or
something similar I am not aware of. A turbocharged version PCF8574 or
something. But if no such beast exists, then an FPGA/CPLD would do the job.

Best regards, Piotr

 

[Jim MacArthur]

If your SPI host is bit-banging and has some control over the timing, I have two ideas that I\'ve used before:

1) Embed CS in the data. Several ways to do this, but one way that I\'ve used requires that data not normally change when the shift clock is high (or low, pick one). So for normal operation, you would set the MOSI data, pulse SCK high then low, then change the data and repeat. Most SPI devices are okay with that. If you can do that, then you can look for transitions on MOSI when SCK is high, which will indicate the beginning of CS. You can then count clock cycles to the end of CS, or use the opposite data transition to signal the end of CS. Lots of variations on this theme are possible.

2) Embed non-SPI control signals in an SPI stream. This is most easily explained by pulling up the schematic of a 74HC595 shift register with output flip flop. Connect MOSI to the serial in (pin 14), SCK to the shift clock (pin 11) and inverted ~CS to the output register clock (pin 12). Now, every time you send data to your SPI device, before you assert CS, you send a few bits, which get loaded into the shift register. Then when you assert CS, those bits get clocked into the output register. Meanwhile, your SPI device wasn\'t paying attention to those control bits while they were being shifted, because CS wasn\'t asserted.

Note that it isn\'t necessary to actually send data to the SPI device to change the control signals. Just shift the bits, pulse CS low and high again. BUT every time you access the SPI device, you _will_ need to always pre-send your control bits. Depending on how many control bits you have, you can toggle them at a decent speed.

Some gotchas: some SPI devices get confused by a CS asserting without bits being clocked, so you need to either make sure yours isn\'t one of them, or only change control bits along with a valid SPI command. Also, avoid the temptation to make one of your control signals reset the SPI device. Many devices get upset when their reset input asserts/deasserts when CS is low. Even if the data sheet doesn\'t mention it, assume the worst. Lastly, I\'ve never tried idea (1) and (2) at the same time. Exercise for the reader, and all.
JMac