SoC with gigabit transcievers - Page 1
Forum section: electronics / general

author: who8877
author_rank: Newbie
timestamp: March 08, 2018, 04:02:00 am
content: 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?

author: ejeffrey
author_rank: Super Contributor
timestamp: March 08, 2018, 05:23:38 am
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: March 08, 2018, 07:29:45 pm
content: 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).

author: Berni
author_rank: Super Contributor
timestamp: March 08, 2018, 08:17:09 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2018, 08:43:00 pm
content: Quote from: who8877 on March 08, 2018, 04:02:00 amPCI 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.

author: asmi
author_rank: Super Contributor
timestamp: March 08, 2018, 09:22:03 pm
content: Quote from: nctnico on March 08, 2018, 08:43:00 pmIt 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.

author: nctnico
author_rank: Super Contributor
timestamp: March 08, 2018, 09:29:23 pm
content: Quote from: asmi on March 08, 2018, 09:22:03 pmNXP's iMX6 and iMX7 have PCI express and are not very expensive (iMX7 is in the $20 range for single units).

author: asmi
author_rank: Super Contributor
timestamp: March 08, 2018, 10:00:50 pm
content: Quote from: nctnico on March 08, 2018, 09:29:23 pmPerhaps 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.

author: asmi
author_rank: Super Contributor
timestamp: March 09, 2018, 01:52:14 am
content: 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: March 09, 2018, 02:39:00 am
content: Quote from: asmi on March 09, 2018, 01:52:14 amPogoplug 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.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: March 09, 2018, 03:37:06 am
content: Quote from: evb149 on March 09, 2018, 02:40:32 amI 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.

author: asmi
author_rank: Super Contributor
timestamp: March 09, 2018, 07:22:31 am
content: 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