DEC’s LAN Bridge 100: The Invention Of The Network Bridge

August 27, 2024 by Maya Posch 12 Comments

DEC’s LAN Bridge 100 was a major milestone in the history of Ethernet which made it a viable option for the ever-growing LANs of yesteryear and today. Its history is also the topic of a recent video by [The Serial Port], in which [Mark] covers the development history of this device. We previously covered the LANBridge 100 Ethernet bridge and what it meant as Ethernet saw itself forced to scale from a shared medium (ether) to a star topology featuring network bridges and switches.

Featured in the video is also an interview with [John Reed], a field service network technician who worked at DEC from 1980 to 1998. He demonstrates what the world was like with early Ethernet, with thicknet coax (10BASE5) requiring a rather enjoyable way to crimp on connectors. Even with the relatively sluggish 10 Mbit of thicknet Ethernet, adding an Ethernet store and forward bridge in between two of these networks required significant amounts of processing power due to the sheer number of packets, but the beefy Motorola 68k CPU was up to the task.

To prevent issues with loops in the network, the spanning tree algorithm was developed and implemented, forming the foundations of the modern-day Ethernet LANs, as demonstrated by the basic LAN Bridge 100 unit that [Mark] fires up and which works fine in a modern-day LAN after its start-up procedure. Even if today’s Ethernet bridges and switches got smarter and more powerful, it all started with that first LAN Bridge.

Continue reading “DEC’s LAN Bridge 100: The Invention Of The Network Bridge” →

Ethernet History: Why Do We Have Different Frame Types?

August 23, 2024 by Maya Posch 9 Comments

Although Ethernet is generally considered to be a settled matter, its history was anything but peaceful, with its standardization process (under Project 802) leaving its traces to this very day. This is very clear when looking at the different Ethernet frame types in use today, and with many more historical types. While Ethernet II is the most common frame type, 802.2 LLC (Logical Link Control) and 802 SNAP (Subnetwork Access Protocol) are the two major remnants of this struggle that raged throughout the 1980s, even before IEEE Project 802 was created. An in-depth look at this history with all the gory details is covered in this article by [Daniel].

The originally proposed IEEE 802 layout, with the logical link control (LLC) providing an abstraction layer.

We covered the history of Ethernet’s original development by [Robert Metcalfe] and [David Boggs] while they worked at Xerox, leading to its commercial introduction in 1980, and eventual IEEE standardization as 802.3. As [Daniel]’s article makes clear, much of the problem was that it wasn’t just about Ethernet, but also about competing networking technologies, including Token Ring and a host of other technologies, each with its own gaggle of supporting companies backing them.

Over time this condensed into three subcommittees:

802.3: CSMA/CD (Ethernet).
802.4: Token bus.
802.5: Token ring.

An abstraction layer (the LLC, or 802.2) would smooth over the differences for the protocols trying to use the active MAC. Obviously, the group behind the Ethernet and Ethernet II framing push (DIX) wasn’t enamored with this and pushed through Ethernet II framing via alternate means, but with LLC surviving as well, yet its technical limitations caused LLC to mutate into SNAP. These days network engineers and administrators can still enjoy the fallout of this process, but it was far from the only threat to Ethernet.

Ethernet’s transition from a bus to a star topology was enabled by the LANBridge 100 as an early Ethernet switch, allowing it to scale beyond the limits of a shared medium. Advances in copper wiring (and fiber) have further enabled Ethernet to scale from thin- and thicknet coax to today’s range of network cable categories, taking Ethernet truly beyond the limits of token passing, CSMA/CD and kin, even if their legacy will probably always remain with us.

A Really Low Level Guide To Doing Ethernet On An FPGA

August 14, 2024 by Lewin Day 7 Comments

With so much of our day-to-day networking done wirelessly these days, it can be easy to forget about Ethernet. But it’s a useful standard and can be a great way to add a reliable high-throughput network link to your projects. To that end, [Robert Feranec] and [Stacy Rieck] whipped up a tutorial on how to work with Ethernet on FPGAs.

As [Robert] explains, “many people would like to transfer data from FPGA boards to somewhere else.” That basically sums up why you might be interested in doing this. The duo spend over an hour stepping through doing Ethernet at a very low level, without using pre-existing IP blocks to make it easier. The video explains the basic architecture right down to the physical pins on the device and what they do, all the way up to the logic blocks inside the device that do all the protocol work.

If you just want to get data off an embedded project, you can always pull in some existing libraries to do the job. But if you want to really understand Ethernet, this is a great place to start. There’s no better way to learn than doing it yourself. Files are on GitHub for the curious. Continue reading “A Really Low Level Guide To Doing Ethernet On An FPGA” →

Manta: An Open On-FPGA Debug Interface

May 1, 2024 by Arya Voronova 30 Comments

We always can use more tools for FPGA debugging, and the Manta project by [Fischer Moseley] delivers without a shadow of a doubt. Manta lets you add a debug and data transfer channel between your computer and your FPGA, that you can easily access with helpfully included Python libraries.

With just a short configuration file as input, it gives you cores you add into your FPGA design, tapping the signals of interest as an FPGA-embedded logic analyzer, interacting with registers, and even letting you quickly transfer tons of data if you so desire.

Manta is easy to install, is developer-friendly, has been designed in Amaranth, and is fully open source as you would expect. At the moment, Manta supports both UART and Ethernet interfaces for data transfer. As for embedding the Manta cores into your project, they can be exported to both Amaranth and Verilog. You should check out the documentation website — it contains everything you might want to know to get started quick.

The Manta project has started out as our hacker’s MIT thesis, and we’re happy that we can cover it for you all. FPGA-embedded logic analyzers are a fascinating and much-needed tool, and we’ve had our own [Al Williams] tell you about his on-FPGA logic analysis journey!

Homebrew Network Card With No CPU

April 10, 2024 by Al Williams 16 Comments

A modern normal network card will have onboard an Ethernet controller which, of course, is a pre-programmed microcontroller. Not only does it do the things required to keep a computer on the network, it can even save the primary CPU from having to do certain common tasks required for communicating. But not [Ivan’s]. His homebrew computer — comprised of 7 colorful PCBs — now has an eighth card. You guessed it. That card connects to 10BASE-T Ethernet.

There’s not a microcontroller in sight, although there are RAM chips. Everything else is logic gates, flip flops, and counters. There are a few other function chips, but nothing too large. Does it work? Yes. Is it fast? Um…well, no.

He can ping others on the network with an 85 ms round trip and serve web pages from his homebrew computer at about 2.6 kB/s. But speed wasn’t the goal here and the end result is quite impressive. He even ported a C compiler to his CPU so he could compile uIP, a networking stack, avoiding the problems of writing his own from scratch.

Some compromises had to be made. The host computer has to do things you normally expect a network card to do. The MTU is 1024 bytes (instead of the more common 1500 bytes, but TCP/IP is made to expect different MTU sizes, which used to be more common when more network interfaces looked like this one).

Even on an FPGA, these days, you are more likely to grab some “IP” to do your Ethernet controller. Rolling your own from general logic is amazing, and — honestly — the design is simpler than we would have guessed. If you check out [Ivan]’s blog, you can find articles on the CPU design, its ALU, and even a VGA video card all from discrete logic. The whole design, including the network card is up on GitHub.

We love the idea of building a whole computer system soup to nuts. We wish we had the time. If you need a refresher on what’s really happening with Ethernet, our [Arya Voronova] can help.

How DEC’s LANBridge 100 Gave Ethernet A Fighting Chance

April 9, 2024 by Maya Posch 17 Comments

Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)

When Ethernet was originally envisioned, it would use a common, shared medium (the ‘Ether’ part), with transmitting and collision resolution handled by the carrier sense multiple access with collision detection (CSMA/CD) method. While effective and cheap, this limited Ethernet to a 1.5 km cable run and 10 Mb/s transfer rate. As [Alan Kirby] worked at Digital Equipment Corp. (DEC) in the 1980s and 1990s, he saw how competing network technologies including Fiber Distributed Data Interface (FDDI) – that DEC also worked on – threatened to extinguish Ethernet despite these alternatives being more expensive. The solution here would be store-and-forward switching, [Alan] figured.

After teaming up with Mark Kempf, both engineers managed to convince DEC management to give them a chance to develop such a switch for Ethernet, which turned into the LANBridge 100. As a so-called ‘learning bridge’, it operated on Layer 2 of the network stack, learning the MAC addresses of the connected systems and forwarding only those packets that were relevant for the other network. This instantly prevented collisions between thus connected networks, allowed for long (fiber) runs between bridges and would be the beginning of the transformation of Ethernet as a shared medium (like WiFi today) into a star topology network, with each connected system getting its very own Ethernet cable to a dedicated switch port.

Ethernet For Hackers: Transformers, MACs And PHYs

March 7, 2024 by Arya Voronova 21 Comments

We’ve talked about Ethernet basics, and we’ve talked about equipment you will find with Ethernet. However, that’s obviously not all – you also need to know how to add Ethernet to your board and to your microcontroller. Such low-level details are harder to learn casually than the things we talked about previously, but today, we’re going to pick up the slack.

You might also have some very fair questions. What are the black blocks near Ethernet sockets that you generally will see on boards, and why do they look like nothing else you see on circuit boards ever? Why do some boards, like the Raspberry Pi, lack them altogether? What kind of chip do you need if you want to add Ethernet support to a microcontroller, and what might you need if your microcontroller claims to support Ethernet? Let’s talk.

Transformers Make The Data World Turn

One of the Ethernet’s many features is that it’s resilient, and easy to throw around. It’s also galvanically isolated, which means you don’t need a ground connection for a link either – not until you want a shield due to imposed interference, at which point, it might be that you’re pulling cable inside industrial machinery. There are a few tricks to Ethernet, and one such fundamental Ethernet trick is transformers, known as “magnetics” in Ethernet context.

Each pair has to be put through a transformer for the Ethernet port to work properly, as a rule. That’s the black epoxy-covered block you will inevitably see near an Ethernet port in your device. There are two places on the board as far as Ethernet goes – before the transformer, and after the transformer, and they’re treated differently. After the transformer, Ethernet is significantly more resilient to things like ground potential differences, which is how you can wire up two random computers with Ethernet and not even think about things like common mode bias or ground loops, things we must account for in audio, or digital interfaces that haven’t yet gone optical somehow.

Continue reading “Ethernet For Hackers: Transformers, MACs And PHYs” →