GigE Micros

[Foxxz]

Are there any MCUs or maybe low cost SoCs that can handle gigabit ethernet throughput? I basically need to build a device that can handle shuffling data between one or more high speed SPI buses (possibly other buses) and a network server.

[martinribelotta]

Are there any MCUs or maybe low cost SoCs that can handle gigabit ethernet throughput? I basically need to build a device that can handle shuffling data between multiple high speed SPI buses (possibly other buses) and a network server.

RISC-V 32b@120MHz with 512K Flash & 96K of RAM
https://www.wch-ic.com/products/CH569.html

Additionally it contain an HSPI (32b) interface at 100MHz (3.2GBPS) and usb 3.0 SS PHY

A complete SDK will be found here: https://github.com/openwch/ch569

A 3rd part board is HydraUSB 3.0:
https://hydrabus.com/hydrausb3-v1-0-specifications/?v=5b61a1b298a0
https://github.com/hydrausb3

That implement a simple board with many of the pins of MCU but not with a PHY ethernet

A board more near of your need may be this:
https://es.aliexpress.com/item/1005005739708092.html?spm=a2g0o.detail.pcDetailBottomMoreOtherSeller.7.cfb5l1xWl1xWAj&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.354490.0&scm_id=1007.40050.354490.0&scm-url=1007.40050.354490.0&pvid=666e92b3-26a3-4d88-8b5f-d589dd3f0f06&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.354490.0,pvid:666e92b3-26a3-4d88-8b5f-d589dd3f0f06,tpp_buckets:668%232846%238115%232000&pdp_npi=4%40dis%21USD%2126.50%2125.17%21%21%2126.50%2125.17%21%402103244b17071768831572799efc40%2112000034172158532%21rec%21AR%212426246840%21AB&utparam-url=scene%3ApcDetailBottomMoreOtherSeller%7Cquery_from%3A

[SiliconWizard]

The CH32V307 can also do Gigabit Ethernet, with an external PHY. The question is whether any of these two can really handle a throughput of ~ 100 MBytes/s (if that's what the OP needs) while doing anything useful in parallel.
Even if there's only data to shuffle around, and you use DMA extensively, the overhead of the TCP/IP implementation on this kind of RISC-V MCU @120/144 MHz will probably never get you anywhere close to that kind of throughput.
If using UDP, that may be possible, but still pushing it.

[brucehoult]

The CH32V307 can also do Gigabit Ethernet

The SRAM should be able to support 400-500 MB/s total bandwidth, so it's not impossible. But only having 64 KB of it means you can only buffer about half a millisecond of data -- about 40 packets, maximum.

Of course if "I need gigE" just means "100Base-T isn't quite fast enough" than that makes things 5-10 times easier.

[Foxxz]

Thank you, all. These are good suggestions. We are possibly looking at going the FPGA route too using something akin to a a Zynq Z7010.

Minimum target speed is 200Mbit/s but more is better. There may be a cost/speed tradeoff too.

[globoy]

Is there a reason something like a Raspberry pi 4 CM on a custom carrier wouldn't work?  It sports GiGE networking and has up to 5 SPI interfaces, a bunch of other interfaces, 4 CPUs plus reasonably fast memory to use to shuffle data around and a traditional set of stacks to program. They're not too expensive if you don't need a lot of memory.   Write your code in C running on a distro like dietPi with fast booting and safe tmpfs filesystems and you wouldn't need much flash or RAM.

[SiliconWizard]

Yes indeed. Still, the benefit of using a MCU or FPGA here is significant, depending on how critical the task is: the "boot time" is virtually zero (usually under 100ms), and there is no possibility of potential filesystem corruption leaving your system unusable until you service it. That alone can be invaluable.

And if you need any kind of system V&V, good luck doing this with something around a RPi, the usual Linux distros available for it, and "random" available libraries that will allow you to access its resources.

But in terms of development time, surely the RPi approach will be much faster and easier.

[brucehoult]

Raspberry Pi aren't very good for doing timing-critical MCU kind of tasks. Yes, you *can* use GPIOs but even if you write a kernel module it's still not that great.

That's where boards such as the Milk-V Duo ($9 with 64 MB RAM, $13 with 256 MB) are nice. There is a 1 GHz core running Linux and a 2nd 700 MHz 64 bit core that you can run an RTOS or just bare metal code on. Unfortunately the ethernet is only 100 Mbps.

The JH7110 SoC has 4x 1.5 GHz Linux cores plus 1x real-time core, dual gigE, and 1 lane of PCIe. You can find that in the StarFive VisionFive 2, Pine64 Star64, Milk-V Mars and Mars CM ($34)

Of course that's a lot more money than an MCU chip, but if you're only building one or a few then that doesn't matter compared to engineering time.

[nctnico]

If you need to shuffle data around at these speeds, you'll need DMA. In such a case you don't need much in terms of CPU power or realtime performance. Depending on the requirements (GUI? web based configuration?) this could be implemented using an RTOS, u-boot or Linux.

[radiolistener]

Are there any MCUs or maybe low cost SoCs that can handle gigabit ethernet throughput? I basically need to build a device that can handle shuffling data between one or more high speed SPI buses (possibly other buses) and a network server.

it's better to build such things on FPGA instead of MCU.

Minimum target speed is 200Mbit/s but more is better. There may be a cost/speed tradeoff too.

look for alexforencich / verilog-ethernet implementation for Ethernet stack, his implement works very well with 10M/100M/1G, also it supports 10G, and 25G packet processing.

I tested it with gigabit streaming through GMII - works very nice and stable. Also it stable detects link speed automatically with no need to access PHY registers.

All what you need is just to encode/decode your SPI data into packets.

[Foxxz]

Are there any MCUs or maybe low cost SoCs that can handle gigabit ethernet throughput? I basically need to build a device that can handle shuffling data between one or more high speed SPI buses (possibly other buses) and a network server.

it's better to build such things on FPGA instead of MCU.

Minimum target speed is 200Mbit/s but more is better. There may be a cost/speed tradeoff too.

look for alexforencich / verilog-ethernet implementation for Ethernet stack, his implement works very well with 10M/100M/1G, also it supports 10G, and 25G packet processing.

I tested it with gigabit streaming through GMII - works very nice and stable. Also it stable detects link speed automatically with no need to access PHY registers.

All what you need is just to encode/decode your SPI data into packets.

Thank you for that link. I have been learning verilog and doing some FPGA work as of late. This will be useful for a multitude of other projects as well.


Nothing has been decided and all options are on the table.

[brucehoult]

Are there any MCUs or maybe low cost SoCs that can handle gigabit ethernet throughput? I basically need to build a device that can handle shuffling data between one or more high speed SPI buses (possibly other buses) and a network server.

it's better to build such things on FPGA instead of MCU.

While true, that's also a whole other level of engineer effort and skill set compared to even bare-metal MCU programming (let alone Linux).

[dobsonr741]

While true, that's [FPGA] also a whole other level of engineer effort and skill set compared to even bare-metal MCU programming (let alone Linux)

Well said. IMO good engineering includes the ability to estimate. Anyone who is married and has done home improvement project can attest to this.

[pcprogrammer]

Well said. IMO good engineering includes the ability to estimate. Anyone who is married and has done home improvement project can attest to this.

Off topic, but most home improvement projects run over budget and time, judging on my own experience and the many TV programs made on this subject. 

Oh my dear wife, we will build this extension in two years tops. Not, it took almost 7 years. Luckily budget wise not that much over.

[glenenglish]

There are STellaris TI cortex M3 microcntrollers

They have an integrated PHY in the package.
"Ethernet connected MCUs" in the document :

https://www.ti.com/en/download/shared/Stellaris_Brochure.pdf

I used LOTS of them successfully for small self contained ethernet designs. I used the s LM3S8962 which had ethernet PHY and CAN

the RAM is a bit small for anythign but fairly simple ethernet facilities.

[pcprogrammer]

There are STellaris TI cortex M3 microcntrollers

They have an integrated PHY in the package.

I checked the brochure and it states 10/100 ethernet PHY. The title of this thread is GigE Micros, so these won't fit.

[dobsonr741]

Raspberry Pi 4/5, with the Circle Bare Metal library. https://github.com/rsta2/circle No linux kernel, just C/C++. Circle for Pi 5 is in the making, in the mean time stay with 4 and swap the board when 5 is needed and ready.

[mac.6]

i.MX RT1160/1170 fit the bill, but 289 bga both. There is RT1180 in 144bga but not available yet.

[radiolistener]

Raspberry Pi 4/5, with the Circle Bare Metal library. https://github.com/rsta2/circle No linux kernel, just C/C++.

what is the reason to deal with bare metal instead of some lightweight linux kernel?

[SiliconWizard]

The CH32V307 can also do Gigabit Ethernet

The SRAM should be able to support 400-500 MB/s total bandwidth, so it's not impossible. But only having 64 KB of it means you can only buffer about half a millisecond of data -- about 40 packets, maximum.

Of course if "I need gigE" just means "100Base-T isn't quite fast enough" than that makes things 5-10 times easier.

Just bumping this thread as a sort of follow-up, as I've been looking for such a solution myself as of late.

I've evaluated the CH32V307 with an external Gigabit PHY (on a CH32V307V-R2 eval board), and things are interesting.

To get started quickly, I first went with WCH's WCHNET library which implements a full TCP/IP stack (but is unfortunately closed source, they only distribute the library in binary form). It did work. It has some quirks, but for a quick solution, it does work. Performance was not exceptional, as we could  expect. I was able to max out at about 12 MBytes/s in both directions using TCP. May be considered not bad for a 144 MHz MCU. But it's just like the max you can get with a 100 Mbps link - something that the CH32V317 provides with an internal 100M PHY.

But, not willing to accept we couldn't do better, I wanted to try and get the most of it by writing my own stack. It doesn't support TCP (yet), but otherwise supports everything needed for UDP. I achieved a sustained raw throughput (UDP payloads) of about 116 MBytes/s, which is close to the maximum achievable on Gigabit ethernet. To get that, I had to enable the checksum offloading that the embedded MAC supports. Works quite well. (With software-computed checksums, throughput was down to 41 MBytes/s.)

Latency is not too shabby either:

Code: [Select]

--- 192.168.1.7 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 10296ms
rtt min/avg/max/mdev = 0.060/0.083/0.199/0.020 ms

Of course, that's raw throughput, and any protocol on top of UDP will have overhead and eat up some of that throughput - still, that confirms that this $3 MCU with a $1 PHY can achieve pretty amazing stuff.

As to other MCUs with Gigabit MACs, there's the iMX RT 1170 and 1180 series, now the STM32N6 as well (same price range). Others that I'm less familiar with, from TI and Infineon.

Back to WCH, note that the CH32V307 is the only MCU they have with a Gigabit MAC. The CH32V317, which has a 100M PHY, only has a 10M/100M MAC.
Even the newer kid, the CH32H417, only has a 100M MAC. That's too bad. I'm guessing that the Gigabit MAC of the CH32V307 didn't meet a market and so they must have decided that there was no point adding one (which is likely slightly more expensive in terms of IP and die area) in newer MCUs.

[hans]

Interesting results! Was that UDP 116MB/s test with constant payload? Did you also try filling the packets with a simple 32-bit test pattern?

Its probably best if the payload data can be filled by hardware somehow.. question is: by what peripheral on this specific MCU. Perhaps USB HS to 1GbE dongle? Or sending raw ADC data over ethernet for some kind of medium speed data logger?
Problem is: USB has flow control while ethernet doesn't (only at TCP level).. Plus the internal ADC isn't terribly fast neither.

1GbE ethernet on a 144MHz micro gives me PIC24FJ64GC006 vibes (10MSPS ADC on 16MIPS CPU + 8K RAM) -- fairly pointless besides a very short burst of sampling.

The CH32V307 only has 64K of RAM. 1GbE transfers almost 1KB of data every 10us, or in this case 1440 processor cycles. Thats just 5.6 cycle/32 bit word. And not a whole lot of space to buffer things for large bursts.. A GbE NIC on a iMX RT1170/80 or STM32N6 looks like a FAR better balance, since those chips run the good part of a GHz clock speed.

[SiliconWizard]

Well the payload content does not matter in this case. Now of course, This MCU has limited performance so in practice, unless indeed strictly copying data from one interface to the MAC buffers via DMA, one's not likely to ever reach ths max throughput, but as Bruce said earlier, you can still manage to get better than what you'd get with a 100 Mb link. It's like USB HS, you don't need to use the full 50 MB/s+ throughput to have relevant uses of it.

As a cool application, we could even just use the CH32V307 + PHY as a fully programmable Gigabit Ethernet/USB HS interface with a FIFO-like interface (for instance using the FSMC interface, which would give you the appropriate bandwidth), connected to another beefier MCU (which wouldn't have ethernet or USB HS), or to a FPGA (if you don't want to bother implementing a full MAC in HDL - the vendor IPs are all licensed and not cheap). All this for about $4 in relatively low quantities, cheaper in large quantities. Can be an interesting option to have up one's sleeve if the added PCB area is not an issue. Always cool to have options.
The Cortex-M7 with Gigabit MACs are pretty much all in the $15-$20 price range.

And the CH32V307, as explained in some other threads, can be configured with 128 KB of RAM / 192 KB of code Flash (which is what I've done for my tests).

So, cool device, and I have some use cases for that in mind.

[LM2023]

Well the payload content does not matter in this case. Now of course, This MCU has limited performance so in practice, unless indeed strictly copying data from one interface to the MAC buffers via DMA, one's not likely to ever reach ths max throughput, but as Bruce said earlier, you can still manage to get better than what you'd get with a 100 Mb link. It's like USB HS, you don't need to use the full 50 MB/s+ throughput to have relevant uses of it.

That, also it's not uncommon that you need a "fast/fat" datalink to handle the whole data exchange of the bigger system the single MCU device is part of.

For example if you have 10..20 boards based on CH32V307 connected to a more powerful supervisor/control device, you may need a GigE datalink to handle the aggregate bandwidth of the MCU devices, not just of a single one.

[SiliconWizard]

Also, latency is significantly reduced with a Gigabit link, if latency matters in your application. Granted that may be niche applications, but as I showed with RTT figures earlier, I could get the lowest RTT on my LAN with this. As a comparison, I have a headless Linux machine with a RT-patched kernel, on the same LAN, behind the same switch and router. RTT is 2.5x higher on it, and it already had pretty good performance thanks to its RT kernel (and obviously a much more powerful CPU).

I'll correct the fact that WCH wouldn't have any other MCU with a Gigabit MAC. There's the CH569, which is a little monster with USB 3.0 SS, a SerDes controller, various peripherals, and a Gigabit MAC. Its max RAM config is only 96 KB though, so less than the 128 KB we can achieve with the CH32V307, but OTOH it has 512 KB of Flash. Pretty interesting chip as well for interfacing needs. It's less than $4 per 100. Imagine that.

[westfw]

I had to enable the checksum offloading

Do you have a good SW checksum algorithm?
There is a lot of room to do the IP checksum inefficiently...