Programmable Hardware Overview (text)
by
Sasha Shkrebets
—
last modified
Mar 20, 2023 08:00 AM
The next series of lectures describe some very exciting developments in
programmable hardware.
Welcome back.
The next series of lectures describe some very exciting developments in
programmable hardware.
In this brief introduction, I'll talk about the motivation for
programmable hardware, and then I'll give a brief overview of the programmable
hardware stack that we'll go into detail on in the next three lectures.
The main problem that programmable hardware developments
are seeking to address, is that protocol evolution is far too slow.
While open-flow allows rapid evolution of the control plane,
the data plane evolves much more slowly.
Likely at the speed of hardware development cycles.
The ambition of the recent movement in programmable hardware is to allow
a developer to define a packet-processing pipeline in a top down
vendor agnostic way.
The definition of the packet-processing pipeline
should also be independent of the target.
In other words it should make sense regardless of whether the target is ASIK,
a network processor, an APGA, or even a software switch.
One important development in programmable hardware was the definition of
a Protocol-Independent Layer.
It allows this switches packet processing pipeline to be defined in terms of
a Protocol-Independent format but then is used to configured the data path.
This effectively decouples switch operation into two stage.
Up to this point in the course, we've really been talking about what's shown as
stage 2 here, or the run-time, whereby you write a control plane program that
configures the data path using a protocol like OpenFlow.
Support for programmable hardware allows the developer to also configure
the data path using high level programming language, like P4 or POF.
We can then use a compiler to instantiate that program on various
hardware targets, and
that compilation process might occur by means of an intermediate representation.
The next three lectures will overview the three components of this ecosystem.
We'll talk about a specific custom target hardware
that is designed to support various custom packet processing pipelines.
We'll talk about a language for configuring a data path called P4.
And then, we'll talk about an intermediate representation that facilitates
the compilation from a high level language, like P4,
to a lower level hardware target, like the RMT chip.