FPGA To Ethernet Direct

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.

19 thoughts on “FPGA To Ethernet Direct

    1. 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.

      1. 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.

        1. 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!”

      2. 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.

        1. 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.

      1. 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.

    1. 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.

  1. 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

  2. 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.