Verilog Ethernet: Work-in-Progress 100BASE-TX PHY
github.com
github.com
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.
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
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.
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.
More power to you and this open source/open hardware/transparent hardware, highly educational project!
Upvoted and favorited!
Wifi 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.