Long distance signalling

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 S ERDES to be constructed or there might be devices with SERDES built in. La ttice is big on small devices and tiny packages. I'd do some digging for y ou, 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

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

MK

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.

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.

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.

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

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

1) Embed CS in the data. Several ways to do this, but one way that I've us ed 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, puls e 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 th en 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 exp lained 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, ever y time you send data to your SPI device, before you assert CS, you send a f ew bits, which get loaded into the shift register. Then when you assert CS , those bits get clocked into the output register. Meanwhile, your SPI dev ice wasn't paying attention to those control bits while they were being shi fted, because CS wasn't asserted.

Note that it isn't necessary to actually send data to the SPI device to cha nge 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-s end your control bits. Depending on how many control bits you have, you ca n 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, a nd all. JMac