When [iliasam] needed an Ethernet connection, he decided to see how much of the network interface he could put in the FPGA logic. Turns out that for 10 Base-T, he managed to get quite a bit inside the FPGA. His original post is in Russian, but automatic translation makes a passable attempt at converting to English.
This is a classic trade off all FPGA designers face: how much external logic do you use for a particular design. For example, do you add memory to the PCB, or use FPGA resources as memory? Each has its advantages and disadvantages (that’s why it is a trade off). However, if you are trying to keep things cheap, slashing external circuitry is often the way to go.
The only thing between the Ethernet cable and the Altera FPGA (with some Verilog inside) is a pair of transformers and a couple of resistors. The Verilog handles all the encoding and decoding. We aren’t sure if it is the translation or just an idiom in Russian, but the post describes this as a “software” implementation, but–as we’ve pointed out before–Verilog on an FPGA doesn’t constitute software in the strictest sense. It describes logic gates that form hardware designs.
This isn’t the first time we’ve seen an FPGA pushed to avoid external devices. Even if it isn’t the right trade for your project, it is useful to have it in your bag of tricks. If you were seriously thinking of trying this, you might mine Opencores to see if any of the Ethernet PHY projects they list are useful to you, as well.
Nice hack, but you can get a LAN8720 for $1, and it’s only 4×4 mm, so the practical value is rather limited.
Well, reducing device count on the board can be very useful. Fewer power rails, fewer nets to route, lower area, lower BOM, and if you can avoid using very small pitch devices, you can use cheaper PCB technology. I think that’s still a good gain, even in a hobby application. And in the grey matter department, it’s good experience.
I agree it’s a good experience. Making stuff yourself is an excellent way to learn how it works.
But practically speaking, the advantages you mention are only worthwhile when doing large volumes. But for large volumes, you don’t want to take chances with the accuracy of the protocol implementation. Note how the author is describing some problems with large packets that was fixed, but without understanding. Possibly, the same problem will resurface in the field, under slightly difference circumstances.
Heh, all valid points. My experience with FPGAs has all been large volumes. 16-layer boards, 0.8mm pitch limits, and not enough board space. And, also assuming proper verification and testing of the FPGA, its IP, the board, and the system into which it goes. Ah, there’s a bad word: “assume!”
Sometimes it is a trap…. using a tried and tested approach might save you a lot more in the long run. Sometimes you can get lucky.
When you are interfacing with external I/O and not following the electrical specs is asking for trouble in the long run.
What’s the deal with the T2 connection? It should be symmetrical for a differential signal and there should be a termination. Yes, this is only 10Mbps, but the design is sloppy.
With the FPGA couldn’t you change to 1000TX with a “software” update rather than producing a new board?
No, because the analog side of 1000TX is (and even 100TX) is more complex. He sort of explains this in the block diagram.
That said, FPGA IO-pins set to differential input mode are often good analog comparators. (I’ve partially verified this on a Spartan 6) With some resistor bias trickery, I think 100TX using about 6-fpga pins would be doable.
No. This is an extremely basic PHY front-end implementation that wouldn’t be suitable for anything above 10 Base-T.
Not to mention 1000tx requires all four twisted pairs, instead of just two pairs like 10/100.
Also 10/100 have dedicated transmit and receive pairs, where gigabit and faster do not and transmit in both directions at the same time.
There is an amazing amount of hardware involved with a current-day 10/100/1000 auto mdi-x ethernet port to make everything work in a backwards compatible way.
It’ll need some DAC/ADC and signal processing to interface with 1000 BaseT.
But do you lose nice things we’ve come to expect these days like Auto MDI-X
not mandatory….. if you have another pair of LVDS TX/RX hanging around, you could get that implemented as well. But considering that most equipment has it, there’s a great chance that what this connects to can do it. You only need one end to be capable of it.
Fpga4fun has a tutorial too
http://www.fpga4fun.com/10BASE-T.html
i have done FPGA gb ethernet before … i hate it … its just not the best platform to get proper gb ethernet and control it
now with A9 processors on FPGA dies i dont think i will ever be doing it again
Need not just be an FPGA, Half-duplex, phyless works on AVRs now, too https://www.youtube.com/watch?v=m4f4OzEyueg … Dunno why my simplex project (which apparently had already been done years earlier) made HaD but the duplex project didn’t… I’m still toying around to see if I can hack half-duplex into an ESP8266.
‘Softovaya’ is jargon for ‘in software’
Wish I could send [iliasam] a link or two.
That said folks, maybe you might shoot him a link to opencores.org
&
hamsterworks.co.nz/mediawiki/index.php/10BaseT-TX
[iliasam] mentioned some issues with LVDS, perhaps he can find a solution among
hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects
FYI – Documentation is excellent AND MIT licensing