GigE Micros - Page 1
Forum section: electronics / general

author: Foxxz
author_rank: Regular Contributor
timestamp: February 05, 2024, 10:02:52 pm
content: 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.

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 05, 2024, 11:49:25 pm
content: QuoteRISC-V 32b@120MHz with 512K Flash & 96K of RAMhttps://www.wch-ic.com/products/CH569.htmlAdditionally it contain an HSPI (32b) interface at 100MHz (3.2GBPS) and usb 3.0 SS PHYA complete SDK will be found here:https://github.com/openwch/ch569A 3rd part board is HydraUSB 3.0:https://hydrabus.com/hydrausb3-v1-0-specifications/?v=5b61a1b298a0https://github.com/hydrausb3That implement a simple board with many of the pins of MCU but not with a PHY ethernetA 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 06, 2024, 12:05:13 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 06, 2024, 12:30:47 am
content: Quote from: SiliconWizard on February 06, 2024, 12:05:13 amThe 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.

author: Foxxz
author_rank: Regular Contributor
timestamp: February 06, 2024, 12:48:37 am
content: 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.

author: globoy
author_rank: Frequent Contributor
timestamp: February 06, 2024, 07:34:48 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 06, 2024, 11:10:54 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 07, 2024, 12:10:54 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 07, 2024, 10:02:54 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: February 08, 2024, 02:22:35 am
content: Quote from: Foxxz on February 05, 2024, 10:02:52 pmit's better to build such things on FPGA instead of MCU.Quote from: Foxxz on February 06, 2024, 12:48:37 amlook foralexforencich / verilog-ethernetimplementation 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.

author: Foxxz
author_rank: Regular Contributor
timestamp: February 08, 2024, 04:11:29 am
content: Quote from: radiolistener on February 08, 2024, 02:22:35 amThank 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 08, 2024, 05:32:32 am
content: Quote from: radiolistener on February 08, 2024, 02:22:35 amWhile true, that's also a whole other level of engineer effort and skill set compared to even bare-metal MCU programming (let alone Linux).

author: dobsonr741
author_rank: Frequent Contributor
timestamp: February 08, 2024, 04:10:16 pm
content: QuoteWell said. IMO good engineering includes the ability to estimate. Anyone who is married and has done home improvement project can attest to this.

author: pcprogrammer
author_rank: Super Contributor
timestamp: February 08, 2024, 07:43:41 pm
content: Quote from: dobsonr741 on February 08, 2024, 04:10:16 pmOff 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.

author: glenenglish
author_rank: Frequent Contributor
timestamp: February 08, 2024, 10:11:59 pm
content: There are STellaris TI cortex M3 microcntrollersThey have an integrated PHY in the package."Ethernet connected MCUs" in the document :https://www.ti.com/en/download/shared/Stellaris_Brochure.pdfI used LOTS of them successfully for small self contained ethernet designs. I used the s LM3S8962 which had ethernet PHY and CANthe RAM is a bit small for anythign but fairly simple ethernet facilities.

author: pcprogrammer
author_rank: Super Contributor
timestamp: February 09, 2024, 07:07:36 am
content: Quote from: glenenglish on February 08, 2024, 10:11:59 pmI checked the brochure and it states 10/100 ethernet PHY. The title of this thread is GigE Micros, so these won't fit.

author: dobsonr741
author_rank: Frequent Contributor
timestamp: February 10, 2024, 11:04:34 pm
content: Raspberry Pi 4/5, with the Circle Bare Metal library.https://github.com/rsta2/circleNo 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.

author: mac.6
author_rank: Regular Contributor
timestamp: February 13, 2024, 08:27:38 pm
content: i.MX RT1160/1170 fit the bill, but 289 bga both. There is RT1180 in 144bga but not available yet.

author: radiolistener
author_rank: Super Contributor
timestamp: February 14, 2024, 04:13:57 am
content: Quote from: dobsonr741 on February 10, 2024, 11:04:34 pmwhat is the reason to deal with bare metal instead of some lightweight linux kernel?

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 28, 2025, 09:08:09 pm
content: Quote from: brucehoult on February 06, 2024, 12:30:47 amJust 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-R2eval 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:--- 192.168.1.7 ping statistics ---100 packets transmitted, 100 received, 0% packet loss, time 10296msrtt min/avg/max/mdev = 0.060/0.083/0.199/0.020 msOf 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.

author: hans
author_rank: Super Contributor
timestamp: September 29, 2025, 08:49:35 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 29, 2025, 08:07:07 pm
content: 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.

author: LM2023
author_rank: Newbie
timestamp: October 01, 2025, 04:59:41 pm
content: Quote from: SiliconWizard on September 29, 2025, 08:07:07 pmThat, 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 01, 2025, 05:49:23 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: October 02, 2025, 08:31:01 am
content: QuoteDo you have a good SW checksum algorithm?There is a lot of room to do the IP checksum inefficiently...

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 02, 2025, 09:39:54 am
content: Quote from: Foxxz on February 06, 2024, 12:48:37 amUnidirectional (MOSI or MISO only) or bidirectional (both MOSI and MISO)?Many microcontrollers and SoCs have two high-speed USB 2.0 peripherals. This includes e.g. Teensy 4.x (NXP i.MX RT1062), which can sustain 200 Mbit/s in one direction indefinitely over plain USB serial (CDC ACM) to a Linux host (so this includes thetermioslayer overhead, which is often the bottleneck here). No need to trust my word for it, either:hereis a test Arduino/Teensyduino sketch and a Linux host C program you can use to verify. It generates a sequence of the most significant 32 bits of each Xorshift64* generated value (which passes all BigCrush tests for statistical randomness, unlike e.g. Mersenne Twister), with the corresponding program on the host supplying the random seed for the sequence, and measuring and verifying the sequence sent by Teensy. So, that is a real-world test, not some "let's see how fast it can send zeros" -type of nonsense.To have both USB peripherals behave as devices, you'd need to modify theTeensyduino coreto expose the second peripheral as a device similar to the first one; normally, the second one is configured as a host (and requires one to solder the connector oneself). Also, note that the host ports must be separate devices also, not just ports on a hub connected to the same USB host port peripheral.(The same tends to apply to most vendor-provided USB implementations when the MCU has two high-speed peripherals, and one or both can act as a host too.)USB 2.0 only has one half-duplex data connection (D+, D- semi-differential signal), so the maximum bandwidth can only be sustained in one direction. Using two in parallel you avoid halving the bandwidth due to payload data flowing in both directions. I do believe that a service daemon running on the Linux host using usbfs I/O to/dev/bus/usb/BUS/DEVcharacter device nodes, bypassing the slow termios serial layer, and exact 512-byte data packets on the microcontroller, using each USB device for one direction only, you should be able to realistically maintain about 320 Mbit/s of payload dataper direction, full duplex, with no interruptions given 128k+128k of buffers (two milliseconds) on the MCU/SoC/device side, if the MCU/SoC RAM can handle that via USB DMA while doing whatever else it needs t do. For smaller device buffering, you usually get bitten by OS scheduling details, as we really do need to treat USB connections as fundamentally asynchronous.(Each SPI connection can use a separate endpoint, for up to 7 SPI devices total; no need to add multiplexing or metadata to the data payload itself.)If you want the electrical isolation that Ethernet offers automagically, do consider using USB 2.0 high-speed isolators like TI ISOUSB211 or Analog Devices ADuM3165/3166/4165/4166. They do not affect the transmission bandwidth at all, although the isolation voltage is somewhat less than that of typical Ethernet magnetics like those in MagJacks.Full disclosure: Ireallylike to use USB between Linux hosts and data acquisition and output devices, and have ever since my very first microcontroller project using AT90USB1286 and ATmega32U4 to make driverless keyboard-like arcade controller. Nowadays, as a hobbyist on the electronics side, I use USB 2.0 HS as an easy, relatively low latency, high-bandwidth set of channels between an embedded Linux host and a MCU-controlled small display panel, mostly to display device status as animations to nontechnical users.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 02, 2025, 02:23:23 pm
content: Quote from: westfw on October 02, 2025, 08:31:01 amWell, I think so, didn't spend a ton of time on it, but I don't see any obvious way of improving it apart from using vector operations on targets that support them (which obviously isn't the case for a CH32V307).I accumulate the checksum on 32 bits - which is pretty much the usual recommended way of doing it, which can also be seen in the RFC.I check alignment of the buffer first. My function checks that the buffer to checksum is at least 16-bit aligned, which is the case with all standard packets. (They're typically not 32-bit aligned due to the fact that the Ethernet frame header is 14-byte long, and Ethernet frame buffers themselves must be 32-bit aligned for the DMA. So you end up with standard headers (IP, ICMP, ...) that are only 16-bit aligned.If the buffer is 16-bit aligned but not 32-bit aligned, I first read and accumulate the first 16-bit word, and then read the rest of the data as 32-bit words (single memory operation) and accumulate for each the upper and lower 16-bit words.If there are remaining bytes after that, I accumulate the remaining 16-bit word if there are more than 1 byte left, and after that, the remaining single byte if any. Finally, the 32-bit sum is folded over 16-bit and negated.I think that's pretty standard, and short of using vector operations or some specific instructions that would fold the sum (which are often also available with vector extensions), I don't see a lot of room for improvement.Anyway, if the MAC you use has a checksum offloading feature (which most do, at least Gigabit MACs), you should definitely use it. Having software checksumming is useful for making your code portable. Also, MACs do not necessarily handle all checksums automatically. For instance, the CH32V307 MAC handles the IP, ICMP, UDP and TCP checksums, but they don't mention IGMP, which also requires a similar checksum. I didn't test it, so maybe it supports it, but it's not documented. So if not, if using IGMP, you'd still need to compute its header checksum in software.

author: gspeed
author_rank: Newbie
timestamp: October 03, 2025, 08:38:11 am
content: I believe CH32V307/317 now has 128KB-Flash/192KB-RAM option.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 03, 2025, 02:13:08 pm
content: Quote from: gspeed on October 03, 2025, 08:38:11 amYes, this mode was undocumented before and now documented in newer versions of the reference manual.But: it's apparently not available on all chips. Beware of the following note:Quote*110：CODE-128KB + RAM-192KBKeep track of your lot numbers.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 03, 2025, 05:56:54 pm
content: One has to be very careful with the lot numbers and related notes in WCH datasheets in general.For example, for the CH32X035 (not a GigE MCU, just an example of a WCH datasheet with lot notes),"I2C function is not available for products with a 0 in the penultimate 5 digits of the lot number".