The Brutal Physical Geometry of an Ethernet Packet
Data demands physical real estate, forcing a tiny ASIC to use cut-through switching because a standard Ethernet packet is geometrically larger than the chip.
By Nolan Chu
Sparked by Designing an Ethernet Switch ASIC · discussion
Software engineers love to talk about the OSI model. To a network programmer, the internet is a beautiful seven-layer cake of pure software abstraction. You start at the application layer where memory feels practically infinite, and you work your way down through transport and network protocols where packets simply flow like water. But down at the very bottom in the unforgiving dirt of the physical layer, bits exist as stubborn, geometric structures that demand actual real estate. And when you try to cram a standard Ethernet packet into the brutal physical constraints of a 180-nanometer silicon floorplan, that beautiful software dream abruptly crashes into a wall of solid geometry.
I recently came across an open-source hardware project where a developer built a tiny custom coffeepot Ethernet switch ASIC. The chip functioned as a real network switch, physically passing data back and forth between ports. But the digital dweebs over on the Hacker News discussion immediately noticed something strange about the silicon design. The ASIC was entirely bypassing the standard store-and-forward networking paradigm. It was using an older technique known as cut-through switching.
This sparked an immediate debate. Readers saw cut-through switching and instantly started debating Wall Street High-Frequency Trading.
They completely missed the punchline.
The community assumed the developer was executing some hyper-optimized latency maneuver to shave microseconds off algorithmic trade times. They thought this was a high-speed routing trick for financial firms. The reality is much more pragmatic. The developer adopted this architecture purely to survive a brutal lack of physical space.
To understand why, we have to talk about the silicon floorplan budget. In modern software development, a kilobyte of data is treated like a rounding error. You allocate it, use it, and forget about it like a sleep-deprived gamer throwing away health potions. But on raw silicon, memory requires physical structures. You cannot just instantiate an array in C++ and expect it to magically exist in the ether.
Let's take a quick timeout to define a 6-Transistor SRAM cell. At its most basic, Static Random Access Memory is the standard method for temporarily holding data directly on a chip. A single bitcell uses six microscopic transistors arranged in a complex feedback loop to remember exactly one bit of data - either a one or a zero.
And every single one of those bitcells requires physical area on the die. When you scale that up to hold an entire packet, the transistor count balloons wildly.
This specific project was designed using the GlobalFoundries 180nm node. In the semiconductor industry's relentless march toward single-digit nanometer nodes, 180-nanometer technology sounds positively prehistoric. But it remains a highly reliable workhorse for analog and mixed-signal devices. It is incredibly cheap to manufacture, but the transistors are objectively large. The metal routing tracks used to wire everything together are wide. Parasitic resistance and capacitance are the stubborn toll trolls of the semiconductor world - entirely unavoidable and deeply annoying - and in an older node, mitigating them requires spacing things out. We need to do some dirty back-of-the-envelope math to see what this actually means for our tiny network switch.
A standard 1,500-byte Ethernet frame is known as the Maximum Transmission Unit. To buffer just one of those packets inside a chip, you need over 12,000 flip-flops or a dedicated SRAM macro block. Every single byte demands eight bits, and every bit demands six transistors, plus all the metal wiring required to connect them without short-circuiting the whole block.
Are you keeping track of the geometry here?
Because the physical space constraint facing this developer was absolutely brutal. This project was manufactured through a Tiny Tapeout educational shuttle. To understand why this matters, it is here that I should take a second to outline the economics of a Multi-Project Wafer. Printing a custom chip requires expensive quartz photomasks to pattern the silicon. If you bear that cost alone, you are staring down millions of dollars in capital expenditure. But a Multi-Project Wafer allows hobbyists and students to print real silicon chips by combining hundreds of tiny designs onto a single wafer.
It is basically the semiconductor equivalent of carpooling. By sharing the astronomical costs of the lithography equipment across hundreds of users, an individual developer can get a custom piece of silicon for a few hundred bucks.
But to make the economics work, the shuttle gives designers a strict microscopic allotment of silicon. The total available area for this entire network switch was a microscopic 711 by 325 micrometers.
We can treat this tiny ASIC area like a cramped Tokyo micro-apartment. The developer had a rigid, immovable amount of square footage to build the memory registers, the control logic, the MAC interfaces, and the routing tables. If the 711-by-325-micrometer silicon tile is the apartment, the 1.5-kilobyte SRAM block required to hold a single Ethernet packet is a massive luxury bathtub.
That bathtub physically exceeds the square footage of the entire apartment.
Yes, really.
Storing and forwarding the network packet is physically impossible. The packet is geometrically too large to exist inside the chip all at once. The moment the Ethernet header enters the switch, the silicon has absolutely nowhere to hold the incoming payload while it waits for the rest of the data to arrive. It would be like trying to park a literal school bus inside that Tokyo apartment.
So the engineering team had to come up with a solution. And fast.
This brings us to how cut-through switching actually works on a component level. Standard network switches receive a whole packet, store it in memory, check it for errors, and then send it on its way. Cut-through switching completely abandons the memory requirement.
The Ethernet protocol is a sequential train of data. First comes the preamble, then the destination MAC address, then the payload, and finally the checksum. Instead of waiting for the entire payload to arrive, the switch aggressively reads the destination MAC address located at the very front of the incoming packet.
The instant the silicon knows where the data is supposed to go, it immediately starts blindly forwarding the rest of the frame out the correct port. It is the network equivalent of building the bridge while you are currently driving a truck over it. The front of the packet is already leaving the switch before the back of the packet has even arrived.
This architecture completely bypasses the need for a massive 1.5-kilobyte SRAM bathtub. The switch only needs enough microscopic memory to hold the six-byte MAC address, vastly reducing the silicon floorplan requirement. It allowed the developer to squeeze a functional Ethernet switch into a sliver of 180nm silicon that otherwise had no business routing network traffic.
But as any good hardware engineer knows, dodging physical limits forces some incredibly messy trade-offs.
Because the chip is forwarding the data instantly, it has no way to verify if the packet is actually intact. It physically cannot run the Frame Check Sequence checksum, which is always located at the very end of the Ethernet payload. You are forced to blindly pass along corrupted frames and let the receiving device sort out the mess.
Furthermore, the extreme silicon diet limits the internal MAC address table to a pitiful four entries. A commercial network switch might track thousands of unique devices on a local network. This chip forgets about a computer if it talks to five different things.
The beauty of networking software is its ability to hide this kind of ugliness. We wrap raw data in protocols and abstraction layers until we forget that at the absolute bottom of the stack, information requires a physical home. Every byte is a geometric shape on a piece of sand.
In the end, there are no magical software workarounds for the sheer physical size of a transistor. You cannot code your way out of geometric reality. Hardware engineers just have to operate within the unforgiving spatial budget they are given.