I'm trying to understand the relevance of Fast Ethernet in the modern world. What are some current use cases? Or is this project primarily of educational value? (I couldn't find anything in the docs.)
Smaller devices that don't need to send or receive more than 100mbits? Devices that don't want to consume more energy than necessary? (I think gigabit is more power-hungry).
RGMII only requires a 125MHz clock; which is not particularly fast. It depends what you mean by "low-end", but you can certainly implement gigabit Ethernet on something like an Intel/Altera MAX 10 for example. It does rather depend on what you want to do with it though.
But if you have IO fast enough to do direct 100Mbps Ethernet, you can do GMII or RGMII to a gigabit PHY (or a parallel to serial converter to talk to an SFP). I think the project here goes through MII internally anyway (I only skimmed it) so it would actually take more space on the FPGA fabric than using a PHY…
So apart from being fun, maybe the main benefit would be less board space because it doesn’t need the PHY chip? (But also potentially lots of disadvantages practically).
Yeah. A Fast Ethernet PHY that does 10/100 Ethernet with auto-negotiation, auto-MDI/MDIX etc. is less than $1 in quantity and fits in a footprint a couple of mm on each side.
Another good exampe is the industrial space. Factory machinery used to communicate over serial type interfaces, but now theres a push to move to EtherCAT which is a determistic protocol built on top of Fast Ethernet.
There is a GigE specification now too, but if all you're doing is controlling some motors you don't need that much throughput.
EtherCAT is not build on top. EtherCAT is just a bit-chain who looks like valid Ethernet frames so that the controller side, and the switch side can handle them like any other regular Ethernet frame. The device aka slaves need a special implementation that just goes through the frame in real-time and changes the bits in real-time and at the end modifies the CRC accordingly in real-time. So, it is not built on top.
EtherCAT is built on top of IEEE 802.3 Frames, you're right that there is a special controller but those interface over MII to a standard Ethernet PHY.
They don't look like valid Ethernet Frames, they are valid Ethernet Frames. Ethercat embeds its Ethertype within the frame the same way that other protocols do.
As you say, EtherCAT does its own thing with the frames, to get the real-time determistic performance it needs, but EtherCAT and other 802.3 Frames can co-exist.
Thanks for referencing. I still have one of the original specification somewhere in my closet, when I was asked to review it.
They are made to look alike valid Ethernet frames. The idea was: how to make Interbus look alike Ethernet and how to make some patents to make money out of it. Originally you had to buy the controllers from Beckhoff. Now they are integrated by many µC, but still they have to pay licensing fees to Beckhoff.
The ESP-32 is a $2 microcontroller that has a Fast Ethernet MAC. It won't handle gigabit, but it can do plenty. Having support for 100BASE-TX solves a lot of problems with Wi-Fi.
There are tons and tons of industrial products that use Ethernet for communication, but don't necessarily need a ton of data. Maybe a C&C machine, or a 3D printer, or an oscilloscope, or an automotive network. For any kind of command-and-control applications, 100 Mbit is more than fast enough. Even 10 Mbit would be plenty for lots of systems.
Around the house, you'll find 100BASE-T Ethernet on wired security cameras, televisions, printers, home-automation, and lots of other stuff too.
As a product designer, there are lots of reasons why I might want to put Ethernet on my widget. It's more robust than wifi, it's lower-power, and it's cheaper. It also has much longer range. I might also like to use Power-over-Ethernet to avoid the need for batteries or an electrical outlet.
Ethernet is also much easier to handle than wifi, from a software perspective. And there are lots of products don't really need more than 10-20 KB/sec of data throughput.
I worked on a product in 2022 that settled on 100BASE-T Ethernet as the right design fit (as a backup to wifi), and it was a great choice for the project. I'd make the same choice again today, for a similar system. 10BASE-T is pretty much gone at this point, but 100BASE-T is alive and well as the lowest common-denominator.
Pretty much all networking gear on the market supports 100BASE-T flawlessly, even if the rest of the devices on the network are 1000BASE-T or 2.5GBASE-T. Almost every laptop (or USB) Ethernet adapter also supports auto-negotiate and auto-crossover, meaning that you could plug your laptop right into some device's 100BASE-T port and start talking to it.
FPGAs are typically a little too pricy for consumer gear, but they're incredibly common in higher-margin commercial, industrial, and military equipment. And if your design already has an FPGA for some reason or another, why not use it to provide Ethernet as well? Cuts down on the number of chips you need to use in your design.
No one is bringing a raw Blu-Ray signal into the back of their TV over Ethernet though— Netflix's 4K streams cap out at around 16mbps, which is a tiny fraction of that.
> No one is bringing a raw Blu-Ray signal into the back of their TV over Ethernet though— Netflix's 4K streams cap out at around 16mbps, which is a tiny fraction of that.
Who cares about internet streamers? Plenty of us definitely are bringing raw Blu-Ray signals in to the back of our TV over ethernet. Disk space is cheap, transcoding is slow and lowers the quality, so when I rip my movies I just do what the pirates call a "remux" where I keep the exact same audio and video streams as are on the disc and just slap them in to a MKV container for my convenience.
It's not super common for UHD Blu-Rays to crack 100mbit/sec but the spec allows for up to 144mbit/sec. I've casually looked in to it in the past and AFAIK Gemini Man is the current leader, with regular spikes to the 120mbit/sec range and one scene transition actually violates the spec by my count, hitting over 150mbit/sec.
Okay, fair. I think that's a use case that would likely be pretty far outside of what the manufacturer would be envisioning when they spec what kind of Ethernet port to put on the TV though— from their point of view it would be purely for firmware updates, spyware, and the built in streaming apps; anything more complicated than that will be coming from an external device through the HDMI port.
Thanks for this - I now realise that I had 10BASE-T and 100BASE-T mixed up when I asked the question.
P.S. Too many generations... I still remember Token Ring and coax Ethernet fighting it out, and even today I run a mix of four different speeds at home, 1G/2.5G/10G and 25G. Everything's become a bit of a blur. :)
100mbit ethernet is very common in industrial use. It is also more robust EMI/RFI and easier to get past EMC certifications.
And 10Base is evolving, not going a way.
Base-T1L spec got recently released. It does full-duplex 10mbit over a single twisted pair.
It is rated for +1000meter cables.
1/10 of the speed of 100BaseTX, but 10x the range.
1Gbps may actually be easier than 100mbps from an EMC perspective. 100mbps links are infamous for trashing HAM frequencies. Indeed, when I played around with my RTL-SDR at home, the FM spectrum was littered with harmonic spikes originating from the one and only 100mbps link I had at the time.
Same reason virtually all keyboards and mice still use USB 1.2: if you don't need the speed, why go through all the trouble trying to design for a way more complicated standard?
You can bitbang USB over a wet string with an ATtiny. If you want USB 2.0 you need dedicated hardware for it in your MCU, and you need to pay some attention to your PCB design. With USB 3.0 you need an expensive MCU, and you need to actually pay close attention to PCB design to ensure the signal remains intact. USB 3.1 and above is basically magic.
The same will apply to Ethernet: stick to the slowest standard which is sufficient for your application to save yourself a lot of headache.
There are several long-range wireless gateways that use Fast Ethernet just because the RF link is the bottleneck. When you run up against physics, there's just no point in supporting a gigabit path in/out.
Yes I have. Any company I've been involved with, met that look at and use, contribute to open source at all (SW as well as HW) avoid AGPL. Many ban employees from downloading, clone something known to be AGPL licensed.
Releasing under AGPL is a great way to not see your design being used and contributed to. At least by entities that wants to abide by the license and do the right thing. Entities that steal work done by others, have no intention to contribute back may do differently.
It's working OK, but honestly that may be because 1) most people don't care about licensing, even the difference between public domain, AGPL, BSD, or GPL, or frankly shareware, or even pirated; and 2) they're running from twitter so they have to go somewhere.
It may have been bit much to say "baby with bathwater", but to fix the analogy maybe I can say "Throw the baby out with the bathwater, but it's fine because you have another baby, and half as many babies ain't too bad. At least it's not zero.".
> The thing that prevents them from contributing is the license that would require them to contribute?
Yes. Because the way it which it mandates upstreaming means that it creates a huge liability and unclear exactly what is in scope of the mandated contributing.
E.g. real lawyers looking at it have said that if you build a web app, and it uses mongodb (AGPL) to store some state, then you may need to opensource your web app.
It's not even clear if the AGPL software needs to be in the serving path. Maybe your billing pipeline uses mongodb, and now you have to opensource your frontend?
The counter argument from AGPL proponents I've seen is almost always "Good. They should need to opensource everything on their servers. I should be able to spin up exactly what they run, on my own servers".
Even a narrower interpretation that only in-scopes your patch to make mongodb work with your in-house SSO means you need to opensource things that you don't necessarily even own.
Again, the answer from proponents is "Good, all in-house SSO should die".
The AGPL and GPL in no way mandate upstreaming, they mandate downstreaming to end-users. It is only via a culture of valuing upstreaming and or the maintenance burden of non-upstreamed changes that upstreaming happens.
If you don't modify the AGPL software, you have no obligations under AGPL at all. The extra network provisions only trigger for modified versions of the software.
I would wager most companies don't modify their database software. Even those that do, don't let end users interact with that database, so should have no obligations either.
Not sure how an Ethernet PHY is part of a proprietary SaaS. Or how “must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version” applies to a PHY.
No, companies that abuse license agreements won't care about AGPL anyway. So the license only makes it impossible for the companies that don't want to abuse your work, but play ball and work with you.
The issue here is liability and what the lawyers counseling a company will recommend. If your design contain IP that the company has valued (very common), risking leakage of that IP by using a library that in legalese seems to suggest that you may have to release your design, you can probably bet that the lawyers will recommend to find another technical solution. Protecting business value and avoid exposure, liability drives conservatism. And in my experience will always triumph over technology choice. Esp if there seems to be a possible choice to be made. Including developing your own solution.
As an open source HW creator I have to decide if I develop stuff for my own amusement, or if I do it to (in somehow small way) help the world - which means other using my creations. And then consider if the license I use support that goal. Since I don't just develop stuff for my own amusement I've decided to use a permissive license since I think that makes it easiest for others to use my stuff.
That's like saying the reason why GNU/Linux was completely lost and every single x86 servers and smartphones for last few decades ran on FreeBSD is because of the MIT license it uses. That would be a complete parallel world imagination.
IMO it's normal and expected that companies hate GPL(v2 or v3 or AGPL). It's not okay but also okay to steal GPL code too, it's just an introductory price phase for inescapable lock-in which even Google hasn't been able to get away from.
an Ethernet PHY layer usually refers to the layer that makes digital signals suitable for transmission on the medium (and the inverse for receiving).
Think for example a standard SoC chip for an embedded device scenario - it will have one or more MII ports [1]. Onto these MII ports, you can then attach a PHY chip for your needs... Ethernet, coax, fiber optics, direct connection, whatever, so you don't need to change your SoC chip or even your operating system just if you want to offer a product with Ethernet and fiber networking.
Usually, these chips are proprietary... but this project provides an open source implementation, so that in the worst case of no one producing Ethernet PHYs any more, you can take an FPGA instead.
100Gbps requires expensive FPGAs because you need very fast SERDES peripherals on-die to transmit/receive the four lanes of 25Gbps to the other device (usually a QSFP28 module but you can communicate directly between two chips with just SERDES without converting to any kind of Ethernet).
Normal logic pins on FPGAs generally can’t be used to transmit or receive fast enough (not to mention some of these standards are using multi-level signalling like PAM-4 which a normal logic pin just can’t do).
100Mbps on the other hand (like this project is doing) is possible to produce, but I do wonder how likely it would be to be able to practically receive with any meaningful cable length without an analogue front-end that you find in a PHY.
Has anyone ever seen an interface that plugs into the MII port pictured in that article? I had a Sun machine with that connector but I never had an adapter for it. There was also a normal RJ45 jack so I didn’t need one but I was always curious.
This is really neat! Lots of FPGAs have MAC peripherals or IP Cores but the PHY is usually an external component.
There are some good reasons for that though, I'm not entirely sure that an FPGA can drive hard enough for a useful Ethernet PHY except for parhaps short range stuff, not sure what happens when the isolating magnetics are added.
I wish there was a good IP Core for the IP Stack though, most implmentations of IP Ethernet on FPGAs use a softcore to run the networking stack which bumps up the utilization a lot. I'm absolutely certain a basic IP layer could be done purely in HDL which would go a long way in getting Ethernet going on lower spec FPGAs.
The OpenHPSDR project implements a good chunk of basic networking without a soft core at 100mbps and 1gbps; ARP, DHCP, and UDP are in there. TCP is not implemented.
Intel have Hard IP in their Stratix/Agilex parts. They've got integrated PCS and PMA in their dedicated transceiver tiles. Agilex supports 10G to 400G too.
Well, in most of the hardware designs I work on you would never want to run anything from the outside world directly into an FPGA. That's a sure way to destroy a very expensive chip. Using robust purpose-built devices with internal and external protection against such things as +/- 15 kV static discharge is important for reliability and more.
66 comments
[ 3.5 ms ] story [ 129 ms ] threadWifi isn't practical for all use cases either.
LiteX allows me to use it as a Gigabit Ethernet powered logic analyzer with a lot of inputs.
So apart from being fun, maybe the main benefit would be less board space because it doesn’t need the PHY chip? (But also potentially lots of disadvantages practically).
I think this is a "because I can" sort of thing.
There is a GigE specification now too, but if all you're doing is controlling some motors you don't need that much throughput.
On top there are other things like ProfinetIO.
They don't look like valid Ethernet Frames, they are valid Ethernet Frames. Ethercat embeds its Ethertype within the frame the same way that other protocols do.
As you say, EtherCAT does its own thing with the frames, to get the real-time determistic performance it needs, but EtherCAT and other 802.3 Frames can co-exist.
https://www.ethercat.org/pdf/english/EtherCAT_Introduction_0...
Slide 25-32 are a good high level overview of possibilities. Slide 32 shows a setup with Co-Existance.
They are made to look alike valid Ethernet frames. The idea was: how to make Interbus look alike Ethernet and how to make some patents to make money out of it. Originally you had to buy the controllers from Beckhoff. Now they are integrated by many µC, but still they have to pay licensing fees to Beckhoff.
Around the house, you'll find 100BASE-T Ethernet on wired security cameras, televisions, printers, home-automation, and lots of other stuff too.
As a product designer, there are lots of reasons why I might want to put Ethernet on my widget. It's more robust than wifi, it's lower-power, and it's cheaper. It also has much longer range. I might also like to use Power-over-Ethernet to avoid the need for batteries or an electrical outlet.
Ethernet is also much easier to handle than wifi, from a software perspective. And there are lots of products don't really need more than 10-20 KB/sec of data throughput.
I worked on a product in 2022 that settled on 100BASE-T Ethernet as the right design fit (as a backup to wifi), and it was a great choice for the project. I'd make the same choice again today, for a similar system. 10BASE-T is pretty much gone at this point, but 100BASE-T is alive and well as the lowest common-denominator.
Pretty much all networking gear on the market supports 100BASE-T flawlessly, even if the rest of the devices on the network are 1000BASE-T or 2.5GBASE-T. Almost every laptop (or USB) Ethernet adapter also supports auto-negotiate and auto-crossover, meaning that you could plug your laptop right into some device's 100BASE-T port and start talking to it.
FPGAs are typically a little too pricy for consumer gear, but they're incredibly common in higher-margin commercial, industrial, and military equipment. And if your design already has an FPGA for some reason or another, why not use it to provide Ethernet as well? Cuts down on the number of chips you need to use in your design.
Netflix streaming isn't exactly a high-bitrate movie either though.
Who cares about internet streamers? Plenty of us definitely are bringing raw Blu-Ray signals in to the back of our TV over ethernet. Disk space is cheap, transcoding is slow and lowers the quality, so when I rip my movies I just do what the pirates call a "remux" where I keep the exact same audio and video streams as are on the disc and just slap them in to a MKV container for my convenience.
It's not super common for UHD Blu-Rays to crack 100mbit/sec but the spec allows for up to 144mbit/sec. I've casually looked in to it in the past and AFAIK Gemini Man is the current leader, with regular spikes to the 120mbit/sec range and one scene transition actually violates the spec by my count, hitting over 150mbit/sec.
P.S. Too many generations... I still remember Token Ring and coax Ethernet fighting it out, and even today I run a mix of four different speeds at home, 1G/2.5G/10G and 25G. Everything's become a bit of a blur. :)
And 10Base is evolving, not going a way. Base-T1L spec got recently released. It does full-duplex 10mbit over a single twisted pair. It is rated for +1000meter cables. 1/10 of the speed of 100BaseTX, but 10x the range.
You can bitbang USB over a wet string with an ATtiny. If you want USB 2.0 you need dedicated hardware for it in your MCU, and you need to pay some attention to your PCB design. With USB 3.0 you need an expensive MCU, and you need to actually pay close attention to PCB design to ensure the signal remains intact. USB 3.1 and above is basically magic.
The same will apply to Ethernet: stick to the slowest standard which is sufficient for your application to save yourself a lot of headache.
CERN-OHL-S seems more common in open hardware.
In general FOSH licenses aren't as developed or tested as FOSS ones.
Releasing under AGPL is a great way to not see your design being used and contributed to. At least by entities that wants to abide by the license and do the right thing. Entities that steal work done by others, have no intention to contribute back may do differently.
AGPL throws the community baby out with the bathwater.
It's working OK, but honestly that may be because 1) most people don't care about licensing, even the difference between public domain, AGPL, BSD, or GPL, or frankly shareware, or even pirated; and 2) they're running from twitter so they have to go somewhere.
It may have been bit much to say "baby with bathwater", but to fix the analogy maybe I can say "Throw the baby out with the bathwater, but it's fine because you have another baby, and half as many babies ain't too bad. At least it's not zero.".
Yes. Because the way it which it mandates upstreaming means that it creates a huge liability and unclear exactly what is in scope of the mandated contributing.
E.g. real lawyers looking at it have said that if you build a web app, and it uses mongodb (AGPL) to store some state, then you may need to opensource your web app.
It's not even clear if the AGPL software needs to be in the serving path. Maybe your billing pipeline uses mongodb, and now you have to opensource your frontend?
The counter argument from AGPL proponents I've seen is almost always "Good. They should need to opensource everything on their servers. I should be able to spin up exactly what they run, on my own servers".
Even a narrower interpretation that only in-scopes your patch to make mongodb work with your in-house SSO means you need to opensource things that you don't necessarily even own.
Again, the answer from proponents is "Good, all in-house SSO should die".
Edit: although, I disagree AGPL is problematic, see my other comment.
https://en.wikipedia.org/wiki/MongoDB https://en.wikipedia.org/wiki/Server_Side_Public_License
https://www.gnu.org/licenses/agpl-3.0.html
AGPL is not LGPL, so is the client library of a client/server thing enough to infect you? Probably.
If there is no client library, what's the license on the example code that you used in your app?
The issue here is liability and what the lawyers counseling a company will recommend. If your design contain IP that the company has valued (very common), risking leakage of that IP by using a library that in legalese seems to suggest that you may have to release your design, you can probably bet that the lawyers will recommend to find another technical solution. Protecting business value and avoid exposure, liability drives conservatism. And in my experience will always triumph over technology choice. Esp if there seems to be a possible choice to be made. Including developing your own solution.
As an open source HW creator I have to decide if I develop stuff for my own amusement, or if I do it to (in somehow small way) help the world - which means other using my creations. And then consider if the license I use support that goal. Since I don't just develop stuff for my own amusement I've decided to use a permissive license since I think that makes it easiest for others to use my stuff.
https://github.com/secworks
Judging by the number of downloads, messages and additional work I've gotten, it seems to work out pretty ok.
IMO it's normal and expected that companies hate GPL(v2 or v3 or AGPL). It's not okay but also okay to steal GPL code too, it's just an introductory price phase for inescapable lock-in which even Google hasn't been able to get away from.
Think for example a standard SoC chip for an embedded device scenario - it will have one or more MII ports [1]. Onto these MII ports, you can then attach a PHY chip for your needs... Ethernet, coax, fiber optics, direct connection, whatever, so you don't need to change your SoC chip or even your operating system just if you want to offer a product with Ethernet and fiber networking.
Usually, these chips are proprietary... but this project provides an open source implementation, so that in the worst case of no one producing Ethernet PHYs any more, you can take an FPGA instead.
[1] https://en.wikipedia.org/wiki/Media-independent_interface
Normal logic pins on FPGAs generally can’t be used to transmit or receive fast enough (not to mention some of these standards are using multi-level signalling like PAM-4 which a normal logic pin just can’t do).
100Mbps on the other hand (like this project is doing) is possible to produce, but I do wonder how likely it would be to be able to practically receive with any meaningful cable length without an analogue front-end that you find in a PHY.
There are some good reasons for that though, I'm not entirely sure that an FPGA can drive hard enough for a useful Ethernet PHY except for parhaps short range stuff, not sure what happens when the isolating magnetics are added.
I wish there was a good IP Core for the IP Stack though, most implmentations of IP Ethernet on FPGAs use a softcore to run the networking stack which bumps up the utilization a lot. I'm absolutely certain a basic IP layer could be done purely in HDL which would go a long way in getting Ethernet going on lower spec FPGAs.
More power to you and this open source/open hardware/transparent hardware, highly educational project!
Upvoted and favorited!