Until Heat Death Do Us Part · Tales on the wire&darr;<br>Skip to main content<br>Tales on the wire

Table of Contents<br>Table of Contents

AI disclosure: All bugs are 100% human made.<br>As regular readers would be well aware I have a thing for terrible ideas. But after an intense schedule working towards taping out my Ethernet switch ASIC my brain was clearly and simply fried. And when a previously closed experimental shuttle re-opened, dangling before me the irresistible allure of free silicon area, I couldn’t come up with a single original terrible idea for what to build.<br>So I did the next worst thing I could think of and asked reddit for advice.<br>And, the r/chipdesign community delivered: there was quite a turnout with a wide mix of horrendous suggestions. Some honorable mentions were to “actually purposefully build an antenna this time” or a “CPU with no cache, no ram and only disk “. But by far my favorite idea came courtesy of “thegreatpotatogod” and was :<br>And I am going to build just that! Also, I only have a little over 48 hours to build this, but since building a counter by itself isn’t ambitious enough I am going to bolt on an 100Mbps Ethernet interface, because I do have at least 48 hours to build this!<br>This article is going to be a short one, but fear not, regular reader, for if you were expecting to spend your afternoon reading a blog post about ASIC design, I have a small novel on designing an ethernet switch from scratch coming down the pipeline for you.<br>ASIC floorplan render targeting the gf180mcuD pdk.Essenceia/Until_Heat_Death_Do_Us_Part

Counting until the heat death of the universe, broadcasting counter every second over 100Mbps ethernet.<br>Verilog<br>18

Heat death is going to take a while<br>Alright, so the plan is to build an ASIC with a large enough counter to theoretically count until the heat death of the universe …<br>Assuming the silicon is clocked at 50Mhz and the counter value is incremented ever 20ns (\(20*10^{-9}\) second) we are going to be in need of a veryyyyyyyyyyyy big counter ….<br>For this design let’s assume the universe is freed of the pesky hassle of thermodynamic free energy in approximately \(10^{100}\) years. I know, I know, this timescale is a hotly debated topic and I could be off by a few factors of 10 but can we at least agree that a googol is an easier number to remember.<br>So, assuming the big freeze arrives in \(10^{100}\) years and we are operating at 50MHz, we have:<br>\(50*10^{6} \) ticks per second<br>\(50*10^{6}*60*60*24\) ticks per day<br>\(50*10^{6}*60*60*24*365.25\) ticks per year<br>\(50*10^{6}*60*60*24*365.25*10^{100}\) ticks until the big freeze<br>So we need a \(log_{2}(50*10^{6}*60*60*24*365.25*10^{100}) = 382.679718 \approx 383\) sized counter &mldr; at the very least. Now let’s round that up to \(384\) bits or a nice \(48\) bytes to make it neatly fit into our Ethernet payload.<br>There are a few issues with building a \(384\) bits counter. Firstly, I need \(384\) bits of storage which, considering how disproportionately big flip-flops are in terms of area, is going to make for quite the large design.<br>Secondly, even if I was to use the most performance optimized type of adder out there, unless I was designing at an advanced node (not my current target of global foundries “180”nm), there is no way this addition is ever meeting timing in a single 20ns cycle.<br>The first problem I can live with, as for the second, I will just need to design around it. Thus, this is the story of how our morbidly obese counter got split into 24 leaner 16 bit counters with the previous counter’s overflow bits cascading into the next.<br>Polluting my local network<br>The more custom logic I design the more I come to fully appreciate well established widely supported protocols. Partly because most of the imprecisions and undefined behaviors have already been ironed out by someone else, partly because this means that, as long as I correctly comply with the spec I can re-use existing infrastructure built and maintained by somebody else. So unless I have an explicit need for something truly custom I would really rather stick with something everyone speaks. And what is more universal than Ethernet?<br>Alright, there might be more universal protocols than Ethernet in terms of absolute number of devices (i2c) or total cumulative bandwidth (PCIe), but Ethernet’s IEEE 802.3 spec is well defined, not behind a paywall, simple, covers a wide range of physical layers at varying bandwidths, and I like it.<br>While working towards building the Ethernet switch I had just built an 100Mbps Ethernet interfacing infrastructure for connecting ASIC accelerators over my local network. And since there isn’t any strong incentive to design a custom parallel bus protocol and all the custom MCU code that goes with it for this ASIC I thought: why not just broadcast over Ethernet ?<br>Now another great thing about Ethernet in the context of this project is that humanity will probably remember how to speak Ethernet for much longer than I can remember how...