chip-to-chip serial comms

[Charlie Martin]

What do you recommendation for serial communications between FPGA chips? We have one FPGA sending configuration information to multiple other FPGAs. The FPGAs will be on different boards. The bandwidth is low, although the message transfer needs to be accomplished in well under a microsecond. We have a limited number of lines, so an addressable serial scheme is desirable.

Previously we have "rolled our own" asynchronous serial protocol and corresponding firmware, and transmitted via LVDS. The drawbacks are that a lot of effort went into both developing the firmware, and solving signal integrity challenges.

I'm wondering what common practices or standard solutions exist? With the generic transceivers now available, what out-of-the box techniques are there for using them? Are there cookbook approaches to designing the signal circuitry? SRIO seems like just the solution, but I really can't tell if it is straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO core is huge).

Thanks for your thoughts,
Charlie

 

[MK]

On 24/01/2014 16:05, Charlie Martin wrote:

What do you recommendation for serial communications between FPGA chips? We have one FPGA sending configuration information to multiple other FPGAs. The FPGAs will be on different boards. The bandwidth is low, although the message transfer needs to be accomplished in well under a microsecond. We have a limited number of lines, so an addressable serial scheme is desirable.

Previously we have "rolled our own" asynchronous serial protocol and corresponding firmware, and transmitted via LVDS. The drawbacks are that a lot of effort went into both developing the firmware, and solving signal integrity challenges.

I'm wondering what common practices or standard solutions exist? With the generic transceivers now available, what out-of-the box techniques are there for using them? Are there cookbook approaches to designing the signal circuitry? SRIO seems like just the solution, but I really can't tell if it is straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO core is huge).

Thanks for your thoughts,
Charlie

Not quite enough timing info to know if this is a good bet but I would
start with SPI, then move to SPI via LVDS, then 4 data line SPI over
LVDS - should be good for 12Mbyte/s easily (nice slow 25MHz clock) but
could possibly get up to 50Mbyte/s.

But if you are seriously contemplating SRIO then you are perhaps hoping
for an order faster than this which would be way out of my league.

Michael Kellett

 

[Theo Markettos]

Charlie Martin <tickranch@gmail.com> wrote:

I'm wondering what common practices or standard solutions exist? With the
generic transceivers now available, what out-of-the box techniques are
there for using them? Are there cookbook approaches to designing the
signal circuitry? SRIO seems like just the solution, but I really can't
tell if it is straightforward to integrate (e.g. the API for the Xilinx
Serial RapidIO core is huge).

If you're on Xilinx, have a look at Aurora for the physical layer. I
haven't used it but it looks a useful building block for a bits-in, bits-out
solution.

The things you have to worry about (in the general case) are:
Crossing clock domains (one transmit clock, plus a clock per receive lane)
Line encoding (8b/10b, 128b/130b or similar)
Stuffing idle symbols when you don't have any data
PLLs and clocking (locking receiver clock on startup, plus handling
powerdown if you ever do that)
Packetisation/reassembly/alignment
Error checking/correction/retransmits

I don't have any experience with RapidIO, but I think it's either that or
roll your own solution (as we did). Most of the other serial formats
(ethernet etc) have too high latency.

Theo