Have you ever programmed an ASIC? I haven’t. But I’ve talked to a lot of people that have. It’s a crazy world that relies on a lot of planning and long timelines. It’s like building out the surveying plan for a village and then trying to shrink it all down like something out of Ant-Man. Then you have to make sure you don’t overheat anything or use the wrong socket interface. Then you send it all off to be mass-produced and integrated into the designs of the things you’re going to use. Sounds easy enough, right?
Space Cases
It reminds me of space exploration in a way. The computer systems onboard Voyager 1 and Voyager 2 were state-of-the-art. In 1974. By the time the probes launched in 1977, the computers were already old technology? Why? Because it takes time to build, test, and harden systems. It takes months or years of effort to get the package built into something. And once that probe launches you can’t recall it and swap out the pieces. You’re stuck with the hardware you have a billion miles from the nearest IT department.
So how has the Voyager program managed to keep running for the last 40 years with almost 50-year-old hardware? They did it because the hardware can be reprogrammed by software without a refresh. The JPL team in charge of the probe can send commands to the probe to reprogram the camera, route around bad circuits, or even reprogram the attitude adjustment thrusters with a 38-hour turnaround for command confirmation. Software is a super powerful method for extending hardware capability.
The parallels to modern ASIC development aren’t too far off. When you program a chip, you have to figure out what features you want baked into it. You have to guess what you want it to do when you design it. Maybe it’s a purpose-built chip for cryptographic acceleration or MPLS. Or maybe it’s a general purpose ASIC designed to do two or three things relatively quickly but not as fast as a purpose-built unit. There are pros and cons to both approaches. But if you gamble on the wrong feature set when you design, you’re going to be stuck with something you can’t use for years. Or you’re going to have to spend the money to design the thing you needed and hope you get it right the next time.
Barefoot Networks is taking a different approach. They’re using software to extend the hardware, just like the Voyager team. Their Tofino chips utilize the P4 programming language to ensure that the functions of the chips can be changed and programmed as needed. To extend our example above, Voyager needed cameras during the Grand Tour of the solar system. But once in the void beyond Neptune, there was no need to take pictures any longer. Instead, it was more important to rely on the other instruments to collect data. In a system that runs with something like P4, you can reprogram the functions to change without needing to rip out the chips and replace them. It’s the height of flexibility.
Arkadiy Shapiro has a great presentation about this strategy and the architecture that allows Barefoot to be so flexible in this video:
During Networking Field Day, Barefoot did a great job of explaining how all this programmability extends the systems they run in. Being able to change the focus of the system’s functionality is a big change in the way we look at ASICs. Instead of guessing and being forced into using something because you can’t change the design, we can now make chips that can be used to do a specific task despite not being engineered for it.
You might say to yourself, “Okay. So how is that going to help me in the long run?” Well, before last year you probably would have benefitted only in the case where you were using networking gear. But in 2019, Barefoot Networks was acquired by Intel in a huge deal. You’ve got the expertise of one of the biggest chipmakers in the world combined with the genius of a team that is making chips more programmable than ever before. It’s a perfect match.
I don’t know how Intel is planning on using the Barefoot technology in the future but I know having access to those capabilities is going to make them rethink the way they design overall. Knowing you don’t have to have everything baked in from the start means you’re free to explore in new directions. Rather than being on the same old road you’ve been on, you can explore in new directions and figure out how to make things work in new combinations you didn’t think were possible.
Bringing It All Together
The challenges of space travel aren’t quite the same as the ones we face in chip design. But the parallels between the two are somewhat relatable. Instead of spending tons of research effort in making something fast and inflexible, we need to instead spend more time building engines to enact policy dictated by language. Changing our methodology to be more flexible means we can do more with what we have for longer periods of time. We can program our systems to do new things instead of just tossing them out every 5-7 years for something that does a different thing a little faster. After all, if a bunch of scientists can keep a space probe working for over 40 years, we can make our switches work a little bit better here on Earth with the help of some software.
