Keeping up with Google Semiconductor

Last week, Google published a paper on its new networking protocol Aquila. This is super cool in its own right, and we planned to write a summary post about it, but two sentences into the Aquila paper we realized there was a whole other post we had to write first. As it turns out, Google also announced a new chip – the Top of Rack in Network Interface Card or the ToR in NIC, which they call the TiN chip. We will get bak to the networking protocol, but here we want to focus on the the TiN, just the latest clue into what Google is doing in chips.

Recall that last year Google launched a video encoding chip, the VCU, the point of that chip was to accelerate the adoption of Google’s favored data compression protocol. In the same vein, the point of the TiN is to enable adoption of Google’s new Aquila networking protocol. One of the most striking features of the the VCU was the fact that it was largely designed by software engineers, the people whose code runs on those chips. In a similar vein, TiN appears to be designed by Google’s networking team. Again, not chip designers or semiconductor experts, but the people who will interface with the chip on a daily basis.

In our research on the VCU we stumbled on Taffel, Google’s internally-designed chip design tools. In that post, we speculated that Google would not have gone to the trouble of designing EDA tools unless they had plans to build many more chips. TiN is just the latest example.

TiN itself is not terribly surprising. The big Internet companies who design their own chips all seem to be working on networking chips. On the other hand, TiN looks like a fairly impressive product, packing a lot of power into what appears to be a fairly small footprint, it is essentially an entire network switch all on its own. In this light, building their own chip makes eminent sense, as Aquila is very different from traditional solutions like Ethernet or Infiniband. TiN is highly modularized, which appears to allow Google to achieve the performance requirements it wants from its network. Put simply, Google wanted Aquilia, and no one else was going to build an Aquila chip for them, so they built it themselves. As we keep saying, build chips that convey strategic advantage, and that is what TiN provides.

A theme we return to time and again with Google is that they are building many chips. This was reinforced by a comment on one of our posts last week from reader Matheus. He linked to a talk given by a senior Google engineer two years ago, who says pretty much exactly what we suspected:

“We are looking at the problem that every team at Google is eventually probably going to have to look at hardware accelerating their workloads”

Put differently, Google is putting in place processes for software engineers to design more of the chips that they will go on to work with day-to-day. (Full credit to Fabricated Knowledge who caught this talk around the time it first came out.)

This is a radical shift in semis. In some ways, it harkens back to the early days of semis when electronics companies were all vertically integrated – AT&T invented semis so they could build better switches to power the telephone network they ran. But the world has changed a lot since then, not least we now have the word “software”. There are probably few companies out there who can do what Google has done – Apple, Amazon, maybe Facebook – but as far as we know, none seem to have the full vision. That being said, this would not be the first time Google has revolutionized the world of software, and it is not unreasonable to see someone creating the tools that Google has and then offering them more broadly to all paying customers. We could end up with any software company being able to build their own chips.

We maintain that Apple is the best run semiconductor company in the world, but Google may very well be the most innovative.

4 responses to “Keeping up with Google Semiconductor

    • good catch. thanks. I wonder how much of this is to use Skywater’s 130nm process, and how much is really about back-end services to help google bring up its chip

  1. It is not clear to me what the tradeoffs for GOOG might be for using a 130nm process for an ASIC vs programing for a leading edge GPU or CPU. What struck me as interesting was that a bunch of other projects that could never justify 130 nm designs on their own are able to ride along on the GOOG wafers. Again I am not sure how this works commercially but it seem like a great way to lower the barrier to entry for semi startups.

Leave a Reply to Dave Cancel reply