APIs for hardware : architecting cellphones and networks

We had two talks by here at UCSD on Tuesday. The first was Cell Phones: How Power Consumption Determines Functionality by Arvind, and the second was Software-Defined Networks by Nick McKeown. These talks had a lot in common: they were both about shifting paradigms for designers, and about approaching the architecture of hardware from a software point of view.

Arvind’s most “controversial statement” is that a hardware architect is actually hampered by too much knowledge of what’s going on at the circuit level. It’s not that you should know nothing about circuits, but more that you should not have to worry about it too much when designing your system architecture. Designing the efficient circuits is “someone else’s problem,” and you should be able to transparently take advantage of that when designing your system. As an example, he showed an OFDM system, which involves a forward error correction (FEC) block and an FFT block. Depending on whether you are doing WiMax or WiFi, these blocks will have different parameters, but from the point of architecture, you don’t want to have to deal with it separately in each case. You’d rather just define an FFT block which has some auxiliary inputs and let other tools synthesize the appropriate block for you from a circuit library. What he was proposing seemed to be an API for these reusable blocks that perform specific functions. He’s designed a system called BlueSpec for this purpose.

Why do you want to do this? It should help speed up the design of specialized hardware for specialized tasks. We need these because a cellphone can only dissipate 3 Watts and so complex software operations need to be given hardware assistance. But developing special chipsets is really expensive now. Hopefully by making it easier to compose functional hardware blocks, you could reduce the cost of development and therefore provide greater functionality in hand-held devices.

Nick McKeown’s talk was about separating the data path (“the plumbing”) from the control plane (“the brains”) in networking in order to allow “experimentation to ride for free on the coat-tails of existing production networks.” This approach of software defined radio is exemplified in the OpenFlow project and OpenVSwitch. In a philosophical sense, his talk was similar to Arvind’s — by creating new abstractions and trying to characterize hardware elements in terms of their behaviors, you can get a kind of software theory of system architecture.

I know this might be a bit of a stretch to say these talks were the same, but I think they are coming out of a similar place — a desire to talk about hardware system designs in a new software-like way. I wouldn’t say it’s antithetical to “cross-layer design”, but it does seem to be at odds with it. Can multiple non-layered abstractions coexist in a productive way?


2 thoughts on “APIs for hardware : architecting cellphones and networks

  1. I think many systems science concepts are now getting embedded in the design of “physical things”. The desire for reusable and efficient systems ends up driving the absorption of concepts that not so long ago were more of a conceptual abstraction than a design and specification process.

    • But do you think that it’s because the “time is right” from the consumer demand standpoint, or that the “time is right” because the tools are there to enable this transformation into design processes?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s