Network middleboxes like firewalls and intrusion detectors increasingly run on FPGAs for speed and updatability, but FPGA development is brutal — every accelerator must be hand-wired into fragile orchestration logic, changes take hours to rebuild, and debugging means squinting at waveforms; this work from UC San Diego wraps a small RISC-V CPU around drop-in hardware accelerators so the orchestration runs as ordinary software, letting hardware experts optimize accelerators and software programmers reuse and debug them like libraries — a firewall built in days and a state-of-the-art intrusion detector doubled to 200 Gbps and ported in three weeks.
The argument in one glance
-
Problem
Middleboxes need FPGA speed, but FPGA development is brutal
Network middleboxes — firewalls, intrusion detectors, SD-WAN gateways — must process packets at 100-plus-gigabit line rates, which pushes them onto FPGAs, and unlike fixed-function ASICs an FPGA can be reprogrammed to patch a bug after it ships. The trouble is that FPGA development is intricate and slow: link speeds have outrun FPGA clock rates, so developers must squeeze every resource with deep knowledge of the chip's memory, layout, and I/O, a bitstream takes hours to build, and debugging means staring at simulation waveforms. So FPGAs end up powering only a narrow slice of middlebox applications.
-
What people did
Write the whole datapath in hardware, by hand
The conventional route is to build the entire packet-processing pipeline in a hardware description language: custom accelerators for the heavy work, plus hand-written control logic to orchestrate them — deciding which accelerator runs when, moving data between them, handling every corner case. Standard interfaces like AXI wire the pieces together, and skilled engineers tune the whole thing to hit line rate.
-
Why it fell short
The hand-written orchestration is fragile and un-reusable
That orchestration logic is the most fragile part of the design. A single mistimed cycle corrupts data in ways that are miserable to track down. Worse, it couples everything: changing one accelerator can break the orchestration and trigger another hours-long compile-and-debug cycle, and integrating a third-party accelerator means adapting its data flow to the rest — so developers usually just reimplement it. And a bus like AXI only connects modules; the orchestration still has to be written by hand.
-
This paper's idea
Let a small CPU orchestrate the accelerators in software
Rosebud wraps each cluster of accelerators around a small RISC-V CPU inside a reconfigurable FPGA block — a Reconfigurable Packet-processing Unit. The CPU orchestrates by calling accelerators like software functions over a shared-memory interface, and a load balancer spreads packets across many such units to reach line rate. The key insight is that orchestration is far cheaper than the accelerator work itself, so even a slow CPU can conduct it without becoming the bottleneck — which turns hardware development into something much closer to writing and debugging software.
Why this problem is worth solving
The devices this framework targets sit on the critical path of every packet in a network. A middlebox is a device that sits in the middle of a network and does something to the traffic passing through it beyond simply forwarding it — a firewall dropping malicious packets, an intrusion detection system scanning payloads for attack signatures, a gateway encrypting a tunnel. Because all of a network’s traffic flows through them, middleboxes have to keep up with the full line rate of the link, which today means 100 gigabits per second and beyond. General-purpose CPUs cannot inspect every packet that fast, so the heavy lifting is pushed onto specialized hardware. FPGAs are the favorite target: they are fast enough for line-rate processing, and, crucially, unlike a fixed ASIC they can be reprogrammed in the field, so a vendor can patch a bug or add a rule after the box is already deployed in a customer’s data center. That combination of speed and updatability is why so much in-network processing is moving onto FPGAs.
The feature that gives FPGAs their updatability is also a major source of their development pain. Partial reconfiguration is an FPGA feature that lets you reprogram one region of the chip’s logic while everything else keeps running. It is what makes runtime updates possible: a middlebox can swap in a new accelerator, or load a fresh set of firewall rules, without taking the whole box offline. The power comes with real cost, though. The reconfigurable regions have to be carved out of the fabric in advance, which constrains where the rest of the design can go and lowers how fully the chip can be used. The boundary of a reconfigurable region needs special border logic to keep the clock fast and to keep the system stable while a region is being rewritten. Getting all of this right takes an experienced developer, and it is exactly the kind of platform-specific complexity that keeps FPGA middlebox development out of reach for most programmers.
What people did before, and where it broke
- Hand-write the whole datapath in Verilog. Build custom accelerators plus the control logic that orchestrates them, tuned by skilled engineers to hit line rate. Where it broke. The orchestration is the most fragile part of the design — a single mistimed cycle silently corrupts packets — and any change cascades into hours-long rebuild-and-debug cycles.
- Connect modules with a standard bus (AXI). Use a well-defined interface so accelerators plug together cleanly. Where it broke. A bus only carries data between modules; it does nothing to decide which accelerator runs when, so all the fragile orchestration logic still has to be written by hand on top.
- Raise the abstraction with high-level synthesis (HLS). Write C-like code and let a tool generate the Verilog. Where it broke. HLS still emits Verilog the developer must understand, its output is typically slower than hand-crafted Verilog, and it offers none of software’s real debugging tools — no breakpoints, no memory dumps.
- Reuse a third-party accelerator. Drop in someone else’s proven block rather than build your own. Where it broke. Its data flow has to be adapted to match the rest of your orchestration, which is often so painful that developers give up and reimplement the accelerator from scratch.
- The gap. Every path left the developer welding accelerators into brittle, hand-timed control logic on a platform where a build takes hours and the only window into a running design is a waveform. What was missing was a way to keep the raw speed of custom hardware while doing the orchestration, the debugging, and the updates the way software developers already know how to — so that a hardware expert and a software programmer could each work in their own idiom.
How Rosebud works
Turning a hardware datapath into software-conducted accelerators
-
-
new
-
new
-
new
-
new
-
new
The idea
Offload the orchestration to a slow CPU, because it is cheap next to the real work. The load-bearing observation is a matter of relative cost. In a middlebox the expensive part is the accelerator work — matching a payload against thousands of attack signatures, looking up an address in a big table — while the orchestration around it, deciding which accelerator to run next and moving a pointer between them, is comparatively trivial. Rosebud pushes exactly that cheap part onto a small, unimpressive RISC-V core running software, where it used to live as brittle hand-timed hardware, and then recovers full line rate by fanning packets across many such cores in parallel. Letting inexpensive software conduct a set of specialized hardware accelerators, so the developer programs the coordination rather than wiring it, is the same division of labor the cooperative-embodied-agent work covered elsewhere on this site adopts, where software running on the host orchestrates a GPU and a custom accelerator that each do the heavy lifting.
Freeze a memory interface between the two sides so hardware and software evolve independently. The reason hand-written orchestration is so painful is that it couples everything: touch one accelerator and the whole control fabric may break. Rosebud replaces that coupling with a single, stable contract — the shared memory between the CPU and the accelerators. As long as both sides speak through that memory interface, passing pointers to where a packet lives, either side can be rewritten without disturbing the other, and an accelerator becomes a reusable component a software programmer can drop in and configure like a library. That is what lets a hardware team optimize accelerators while a software team reuses and debugs them. Splitting a hard problem across a clean interface so each side can be understood and changed on its own is the same modular discipline the on-chip-memory-allocation work covered elsewhere on this site depends on, carving a tangled whole into pieces with well-defined boundaries that can be reasoned about separately.
Once control is software, the whole software toolbox comes along. Native FPGA development is starved of visibility — a build takes hours and the only view into a live design is a waveform — which is why bugs are so costly to chase. By moving the datapath’s control onto a CPU, Rosebud makes the design inspectable the way a program is: the host can pause a unit, set breakpoint-like conditions, inject or drop packets to test a hypothesis, and dump an entire unit’s memory to see its state, and the whole thing can be exercised in a Python simulation before ever being placed on the chip. Bringing the debugging idioms of one level of the system down to a level that normally lacks them, so a symptom can be probed where it happens, is the same bridging the cross-level debugging work covered elsewhere on this site performs, tying together layers that are usually inspected in isolation so a developer can reason across them.
Following the reasoning through Rosebud
Building a blacklist firewall from scratch
The paper's second case study builds a working 200-gigabit firewall, showing how little the developer actually has to do.
Step 1 of 5
The goal: drop blacklisted IPs at line rate
The task is a firewall that checks every packet and drops any whose source address is on a blacklist of about a thousand IPs, forwarding the rest. It must do this at 200 gigabits per second, checking every single packet, which is exactly the kind of workload that forces a middlebox onto an FPGA.
The blacklist comes from a public "emerging threats" ruleset of 1050 addresses.
Why it works
- Because orchestration is cheap, a slow CPU can run it without becoming the bottleneck. Deciding which accelerator runs when and shuffling data between them is lightweight next to the actual pattern-matching or lookups → so it can run as software on a wimpy RISC-V core rather than as brittle hand-timed hardware → and with packets fanned across many such cores, the aggregate still reaches 200 gigabits per second.
- A shared-memory interface lets hardware and software change independently. Hand-written orchestration welds every accelerator to the rest of the design, so one change cascades → but if the CPU and accelerators only ever talk through a fixed memory interface, either side can be swapped without disturbing the other → so a hardware team optimizes accelerators while a software team reuses and configures them like a library.
- Running control in software drags software’s whole toolbox onto the FPGA. Native FPGA debugging means hours-long builds and reading waveforms → but once the datapath is conducted by a CPU, the host can set breakpoints, inject or drop packets, and dump an entire unit’s memory at runtime → and the design can be simulated end to end in Python before ever touching the chip.
- Spreading packets across parallel units turns slow cores into line rate. A single RISC-V core forwarding a packet every sixteen cycles could never keep up with a 200-gigabit link → but a load balancer distributing packets across sixteen such units multiplies the throughput → so the framework reaches full line rate for all but the very smallest packets while sparing the developer from hand-parallelizing anything.
- Splitting memory by access pattern serves random and streaming traffic at once. Accelerators stream payloads while the CPU jumps randomly around packet headers, and one memory cannot do both well → but Rosebud copies headers into small fast memory for the CPU and streams payloads through large pipelined memory for the accelerators → so each gets the memory it needs without fighting over ports.
What it costs (trade-offs and scope)
- The software becomes the bottleneck for tiny packets. Each RISC-V core forwards a packet every sixteen cycles, capping throughput at 250 million packets per second with sixteen units, so 64- and 65-byte packets reach only 88 to 89 percent of line rate. The premise that orchestration is cheap strains exactly at the smallest packet sizes.
- The framework itself consumes real FPGA area. Before a single accelerator is added, the sixteen-RPU base uses about 22 percent of the chip’s logic, 25 percent of its block RAM, and 65 percent of its wide URAM memories, and the packet-switching fabric alone eats over half the die-crossing registers. The authors argue this is marginal versus custom designs, but it is not free.
- The headline intrusion-detector result leans on an assumed hardware engine. They actually ran the detector’s TCP flow reordering in software, which is slower — about 100 gigabits per second at 800-byte packets — and the full 200-gigabit figure assumes a hardware reorder accelerator they did not actually port.
- Runtime updates are no-downtime but not instant. Swapping an accelerator via partial reconfiguration takes about 756 milliseconds on average; the load balancer offloads traffic to other units during that window, but the region itself is out for most of a second.
- The CPU comparison is arranged to isolate one operation. The win over a 32-core Snort server on pattern matching is real — the FPGA’s pipelined matching beats the CPU’s sequential vector instructions — but it compares that specific stage, not a whole system end to end.
- Hitting line rate still takes careful software craft. A 30 percent packet-rate swing came from reordering the members of a struct and applying a compiler bug fix, so the framework does not make performance automatic; it still rewards attention to the RISC-V code and toolchain.
- The evidence is two apps on one board, built by the authors. A firewall and a Pigasus port, on a single Xilinx board with one RISC-V core; the framework’s generality across other middleboxes, FPGA families, and independent developers is argued rather than broadly demonstrated.
The evaluation
Ways to build a line-rate middlebox datapath
| Property | Hand-written Verilog | High-level synthesis | Software middlebox (CPU) | Rosebud |
|---|---|---|---|---|
| How the datapath is orchestrated | ||||
| Debugging | ||||
| Accelerator reuse and runtime update | ||||
| Line-rate throughput | Below hand Verilog | |||
| Development effort | Months of expert work | Still needs hardware expertise | Familiar, but too slow |
Check yourself
Check your understanding
1. Why is developing FPGA-accelerated middleboxes so painful in the conventional approach?
2. What is Rosebud's core idea?
3. How does moving orchestration into software change FPGA development for the better?
4. Which statement best reflects the limits of Rosebud's results?
Sources
The paper is “Rosebud: Making FPGA-Accelerated Middlebox Development More Pleasant” by Moein Khazraee, Alex Forencich, George C. Papen, Alex C. Snoeren, and Aaron Schulman, published at ASPLOS 2023; the full text used here is the arXiv version, arXiv:2201.08978v3. The authors are at the University of California, San Diego, and Rosebud is open-source.
This explainer is written from the full text. Everything above comes from the paper’s own sections: the introduction and challenges laying out why FPGA middlebox development is hard (tailoring logic to platform-specific resources and partial reconfiguration, orchestrating parallel accelerators with fragile control logic, and slow builds with waveform-only debugging); the processing abstraction introducing the Reconfigurable Packet-processing Unit, its shared-memory interface between a RISC-V core and accelerators, and the insight that orchestration is far cheaper than accelerator work; the hardware design of the tailored three-part memory subsystem (small low-latency memory for the core, large pipelined memory for streaming accelerators, and a shared packet scratchpad with a DMA engine), the customizable load balancer, the two-stage packet-distribution switch that exploits middleboxes’ tolerance for microsecond latency, and the loopback and broadcast inter-RPU messaging; the implementation on a Xilinx Virtex UltraScale+ VCU1525 board with 8- and 16-RPU layouts using the VexRISC-V core and Corundum NIC, meeting timing at 250 MHz with the reported resource utilization; the evaluation showing 200-gigabit forwarding for most packet sizes (88 to 89 percent for the smallest), 0.765-microsecond minimum latency, the 250-million-packet-per-second software limit, and inter-RPU messaging latencies; and the two case studies — porting the Pigasus IDS to double it to 200 gigabits per second in under three weeks (including runtime ruleset reconfiguration and a software TCP-reordering variant, and a comparison to Snort on a 32-core Xeon) and building a blacklist firewall from a Python-generated IP-lookup accelerator plus a few lines of RISC-V C — both completed by one developer in under a month.