SoC with gigabit transcievers

[who8877]

I'm working on an FPGA design that is IO and area limited.  One idea was to replace some of the slower on board logic with an off-chip CPU (a soft CPU is too slow).  However the data rate required is on the order off 800 Mbits/s and there aren't enough regular IO to transfer this in parallel.  Zynq is another option I know, but I wanted to price out a two chip solution.

SoC makers don't really advertise GBTs in the way FPGA vendors do.  Does anyone know of some good options?

[ejeffrey]

SoCs don't generally have generic gigabit transcievers in the same way that FPGAs do.  Even if it did, few CPUs could keep up with that data rate in a "bit banging" mode, at least if you want it to do anything else.  Your best bet is to find a higher level protocol that the SoC supports -- PCIe, USB3, MIPI camera interface, gigabit ethernet, or whatever.  Then have the FPGA implement that protocol with its high speed transceiver.

[asmi]

Check if your FPGA has SERDES resources which can be used to output hi-speed serial signals. For example Artix-7 has [I|O]SERDES which can go up to 1250 Mbps depending on the speed grade - even slowest (-1) speed grade can go up to 950 Mbps per pin pair. I used it on my board to output HDMI signals to the monitor, and had no problems running up to 1080p@30Hz or 720p@60Hz (~800 Mbps per data lane).
But as usual with hi-speed traces, make sure your transmission lines are controlled-impedance and routed properly over reference plane. If you need to send this signal somewhere off-board, I suggest you to use SATA cables and connectors as they are very cheap and rated up to 6 Gpbs (each cable has two differential pairs with 100 Ohm differential impedance).

[Berni]

You can get to 800Mbit on some more consumer FPGAs if you take the higher speed grades.

But if you want actual superfast transceivers there are the Cyclone V SX chips that have a dual core ARM along with 6Gbit/s SERDES. Still won't be cheap but that's likely the cheapest family out there.

[nctnico]

I'm working on an FPGA design that is IO and area limited.  One idea was to replace some of the slower on board logic with an off-chip CPU (a soft CPU is too slow).  However the data rate required is on the order off 800 Mbits/s and there aren't enough regular IO to transfer this in parallel.  Zynq is another option I know, but I wanted to price out a two chip solution.

SoC makers don't really advertise GBTs in the way FPGA vendors do.  Does anyone know of some good options?

PCI Express would be my first choice. Some Spartan6 FPGAs have a hardware PCI express block built in and that will be the easiest way to get data to and from your SoC.

[asmi]

PCI Express would be my first choice. Some Spartan6 FPGAs have a hardware PCI express block built in and that will be the easiest way to get data to and from your SoC.

It depends on what's on the other side. Not many cheap CPUs have PCIE lanes exposed, and those that do are probably not that much cheaper than Zynq MP/UltraScale+ (latter start at ~$215 and provide quite a bit of stuff of the money, including fast fabric and DDR4 support). Also PCIE block (at least on 7 series) is quite a low level component, so doing anything useful with it requires quite a bit of additional logic. MB soft core + x32 DDR3 controller + memory-mapped PCIE endpoint did not fit into A50 according to my tests.

But if the project is dead-set on having dedicated CPU (and not SoC), then the real question is what kind of high-speed peripheral is available in CPU.

[nctnico]

PCI Express would be my first choice. Some Spartan6 FPGAs have a hardware PCI express block built in and that will be the easiest way to get data to and from your SoC.

It depends on what's on the other side. Not many cheap CPUs have PCIE lanes exposed,

NXP's iMX6 and iMX7 have PCI express and are not very expensive (iMX7 is in the $20 range for single units).

[asmi]

NXP's iMX6 and iMX7 have PCI express and are not very expensive (iMX7 is in the $20 range for single units).

Perhaps I didn't phrase it quite right, but I meant that the total cost of adding CPU (beefier FPGA to accommodate logic to communicate with CPU, additional board space/more advanced process, power solution, dedicated memory, etc.) IMHO is going to be higher than swapping the FPGA for SoC with integrated ARM cores.

[asmi]

Another solution I just thought of could be using dedicated deserializer IC on the receiver side - so it would be possible to use any CPU with parallel port. But even at 1:8 deserialization we're talking about 100 MBytes/s, so you will need quite beefy CPU to process that kind of data stream.

[NiHaoMike]

Another solution I just thought of could be using dedicated deserializer IC on the receiver side - so it would be possible to use any CPU with parallel port. But even at 1:8 deserialization we're talking about 100 MBytes/s, so you will need quite beefy CPU to process that kind of data stream.

Pogoplug will run iperf at very close to gigabit speed - something like 950Mbps. Of course, how much CPU you really need is all dependent on what you want to do with it. Getting a lot of bandwidth on plain GPIOs is asking for a lot, so you'll most certainly have to go to some higher level interface. SATA might be your best bet, with PCIe a distant second.

[chickenHeadKnob]

I would go with PCIE if using a FPGA + SOC solution, though I'd probably just use a Zynq personally.

Secondarily you could look at SOCs which have multiple (two may be too few, three or four could about do it) independent Gbit-Ethernet MACs built in (GMII, or RGMII for instance) along with a GOOD internal ethernet controller that can handle nearly line rate sustained throughput which is divided between the N interfaces  if that is what you require throughput-wise.
Usually good ethernet controllers have nice buffers / FIFOs / DMA support etc.

The other possibility would be a SOC with an EMIF -- external parallel  memory interface -- which is capable of talking to something fast and wide enough at the right sustained throughput -- SRAM or wide DDRx memory or preferably a fast streaming DMA interprocessor communications bus rather than a memory oriented one.  Then you should be able to implement the other  side of that on your FPGA.

I don't suspect that a sufficiently capable SOC plus a minimal FPGA will be less expensive overall than just buying a Cyclone-V-SOC or Zynq or some such device that has hard cores as well as FPGA PL.

I would use caution here. I thought that ARM A7-A9 application cores were limited to a max effective throughput of 400Mb/sec on Gbit ethernet because of saturation on one of their internal busses. Can't remember were I read it, but the limit comes strait from the ARM holdings design, not some vendor specific implementation. I suspect it would also apply to zynq/other soc cores once you leave the fpga fabric.

[asmi]

It's mentioned in OP that softcore is too slow for on-chip processing. Perhaps this part can be sped up by implementing part of processing in hardware, and/or implementing several softcores inside FPGA and splitting processing among these cores? It's hard to say anything definitive without knowing the nature of data and processing required