Co-Exploration of RISC-V Processor Microarchitectures and FreeRTOS Extensions for Lower Context-Switch Latency

Embedded devices that must react to events within strict deadlines run a real-time operating system to juggle tasks, but every time the system switches from one task to another it must save one task's registers, pick the next task, and restore its registers — a delay that eats into how fast the device can respond, and whose unpredictability wrecks the worst-case timing guarantees safety-critical systems need; this work from TU Darmstadt builds RTOSUnit, a configurable hardware block for RISC-V processors that does the scheduling and register save/restore in hardware and even preloads the next task in the background, cutting switch latency by up to 76 percent and letting it be made perfectly predictable.

The argument in one glance

Problem

Switching tasks in an RTOS is slow and unpredictable

Real-time embedded systems use an RTOS like FreeRTOS to juggle tasks, but every context switch must save one task's registers, run the scheduler, and restore the next task's registers. This latency limits response time, and its variability (jitter) undermines worst-case timing guarantees.
What people did

Do scheduling and context switching in software

Implement the RTOS scheduler and the register save and restore entirely in software, as FreeRTOS does, running them on the same processor as the tasks.
Why it fell short

Software switching is hard to make fast or deterministic

Saving and restoring registers instruction by instruction, and running a variable-time scheduler, keeps both the latency and the jitter high. Since complex event handling must be deferred to a task behind a full context switch, this directly slows response and complicates the worst-case timing analysis safety-critical systems require.
This paper's idea

Accelerate scheduling and context switching in hardware (RTOSUnit)

RTOSUnit is a configurable RISC-V hardware unit, tightly coupled via custom instructions, that offloads task scheduling and register save/restore, duplicates the register file to save state in one cycle, and can preload the next task's context in the background. Configurable from lightweight to full support and portable across three cores, it cuts mean switch latency by up to 76 percent and can eliminate jitter entirely.

Why this problem is worth solving

Real-time embedded systems live or die by how fast and how predictably they react, and the operating system that makes them easy to build sits right in that critical path.

An embedded real-time system must respond to external events — a sensor reading, a timer, a fault — within strict, guaranteed time bounds, because being late can mean a safety failure. A real-time operating system (RTOS) such as FreeRTOS makes these systems far easier to build by offering a multi-tasking model: developers write several concurrent tasks that coordinate through synchronization primitives, instead of hand-crafting one monolithic bare-metal program. The cost of that abstraction is the work the RTOS must do to manage tasks, and the central piece is the context switch. When the system stops running one task and starts another — triggered by a timer, a peripheral interrupt, or a task voluntarily yielding — the RTOS must save the current task’s register state to its stack, invoke the scheduler to choose the next task to run, and restore that task’s saved register state before resuming it. The total time this takes is the context-switch latency, and it matters directly for responsiveness: simple events can be handled inside the interrupt service routine, but anything more complex must be deferred to a task, which cannot begin until a full context switch completes, so the switch latency sets a floor on how quickly the system can react.

Beyond raw speed, real-time systems need timing to be predictable, and doing this work in software fights both goals.

Real-time correctness is not only about being fast on average but about being provably fast enough in the worst case, which is why designers perform worst-case execution time analysis to certify that every deadline is met even under the worst conditions. Context switching complicates this because its duration is not constant: different scheduling decisions and task states make some switches take longer than others, and the spread between the longest and shortest observed switch is called jitter. Jitter is corrosive to predictability — it widens the worst-case bound and makes tight timing analysis harder, which is especially damaging in control loops or under heavy load where switches are frequent. Implementing the scheduler and the register save and restore in software, as a conventional RTOS does, keeps both problems large: saving and restoring the register file happens one register at a time through ordinary instructions, the scheduler runs as variable-length code, and all of it competes for the same processor that runs the tasks. So a software RTOS pays a latency it struggles to shrink and a jitter it struggles to eliminate, degrading exactly the responsiveness and predictability the system was built to guarantee.

What people did before, and where it broke

Do everything in software (standard FreeRTOS). Run the scheduler and register save/restore as ordinary code on the main processor. Where it broke. Saving registers one at a time and running variable-length scheduler code keeps both latency and jitter high, directly limiting response time and complicating worst-case analysis.
Offload scheduling to a memory-mapped hardware unit. Add a hardware scheduler that the processor talks to through memory-mapped I/O. Where it broke. Communicating over the memory-mapped interface adds latency and overhead on every interaction, blunting the benefit of the hardware.
Use shadow or banked register sets for fast switches. Give interrupts their own register bank (as ARM’s fast-interrupt mode or some microcontrollers do) so no save/restore is needed. Where it broke. The inactive banks are inaccessible to software and fixed in number, so they suit short interrupt handlers but cannot support general context switching among arbitrarily many tasks.
Give each task its own register file in hardware. Switch tasks by switching register banks, eliminating save/restore. Where it broke. This caps the number of tasks at the statically-provisioned bank count and costs large hardware area, so it does not scale to real workloads.
The gap. No design accelerated general scheduling and context switching, tightly coupled to the processor, configurably, and portably across cores while cutting both latency and jitter. Providing that is what RTOSUnit does.

How RTOSUnit works

From software context switching to a tightly-coupled hardware unit

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Move the costly RTOS operations into the processor as first-class instructions. RTOSUnit’s foundation is to accelerate the two operations that dominate a context switch — scheduling and register save/restore — in dedicated hardware, and, crucially, to reach that hardware through new custom instructions rather than a memory-mapped interface, so the processor triggers it as tightly as any native operation with almost no communication overhead. This makes the RTOS’s hot path part of the processor’s own repertoire instead of a distant peripheral. Specializing the processor with custom instructions that build a targeted operation directly into the datapath, so a costly software routine becomes a fast hardware primitive, is the same move the ISA-specialization work covered elsewhere on this site makes, extending the instruction set and the processor so that the operations a workload depends on are executed natively rather than emulated in slow general-purpose code.

Make the state transfer itself nearly free and deterministic. The bulk of a software switch is copying the register file out and back one register at a time, so RTOSUnit duplicates the register file and copies the whole task state into a second bank in a single cycle, then drains it to memory in the background while the processor runs on — turning a long, variable sequence of loads and stores into a fixed, tiny operation. Because the copy is constant-time and decoupled from memory, this is what lets the switch be made not just faster but perfectly predictable, eliminating jitter on suitable cores. Driving down the cost of the transition between execution contexts so that switching is cheap and uniform, rather than a heavy, variable operation, is the same concern the exit-less virtual-machine work covered elsewhere on this site addresses, removing the expensive, disruptive control transfer that a naive design pays every time execution crosses a boundary.

Hide the restore by fetching the next task ahead of time. Even with a fast save, restoring the next task’s registers from memory takes time, so RTOSUnit adds an optional preloading mechanism that speculatively loads the incoming task’s context into a buffer in the background, at lower memory-arbitration priority than the processor so it never steals cycles from running work; when the switch occurs, each saved register is immediately overwritten with its already-fetched replacement, so the restore latency is largely hidden. Overlapping a data transfer with ongoing computation by prefetching what will be needed before it is needed, so the wait is absorbed rather than exposed, is the same design the prefetching-in-unified-memory work covered elsewhere on this site is built on, moving data toward the compute ahead of demand so that when it is required the latency has already been paid in the background.

Following a context switch through RTOSUnit

Switching tasks with hardware acceleration and preloading

A trace of RTOSUnit handling a context switch on a RISC-V core, following the paper's co-designed hardware-software approach.

Step 1 of 5

An event triggers a switch

A timer, peripheral interrupt, or voluntary yield causes the RTOS to switch away from the running task. Complex handling for the event will run in a task, so it cannot begin until the switch completes.

The switch latency sets the floor on response time.

Why it works

Custom instructions avoid the communication tax. Because RTOSUnit is reached by native instructions rather than memory-mapped I/O → the processor invokes its functions with almost no interface overhead → so the acceleration is not blunted by the cost of talking to a peripheral.
A one-cycle register snapshot replaces a long sequence. Because a duplicated register bank copies the whole state at once and drains it in the background → the save is constant-time and off the critical path → so the largest part of the switch shrinks dramatically and becomes uniform.
Hardware scheduling removes variable-length code. Because selecting the highest-priority ready task is done in hardware → the scheduler no longer runs as jittery software → so a major source of timing variability is eliminated.
Background preloading hides the restore. Because the next task’s context is fetched ahead of the switch at low memory priority → the restore is mostly complete when needed and steals no cycles from running work → so the restore latency is absorbed rather than paid on the critical path.
Determinism follows from constant-time operations. Because each accelerated step takes a fixed time independent of task state → the whole switch can be made constant-duration → so jitter can be eliminated, tightening worst-case timing analysis.

What it costs (trade-offs and scope)

It adds hardware area. Accelerating the switch, especially duplicating the register file, costs silicon: in 22-nanometer ASIC implementations the area overhead ranges from negligible (within the design tool’s measurement noise) for lightweight configurations up to 44 percent for full support. The configurability lets designers trade area for speed, but the strongest configurations are not free.
It requires modifying the processor core. RTOSUnit adds custom instructions and duplicates the register file, so it must be integrated into the core’s pipeline and register file rather than bolted on externally. The paper demonstrates this on three RISC-V cores, but each integration is real engineering.
The biggest gains need the heaviest configuration. The up-to-76-percent latency reduction and full jitter elimination come from accelerating store, load, and scheduling together (and preloading); lighter configurations that add little area deliver smaller improvements, so the benefit tracks the investment.
It is specific to FreeRTOS and RISC-V here. The design accelerates FreeRTOS’s scheduling and context-switch mechanisms on RISC-V cores. The principles generalize, but the concrete implementation targets this RTOS and instruction set, and porting to others is additional work.
Preloading is speculative. The preloading mechanism speculatively fetches the anticipated next task; if the scheduling decision differs, the speculation is wasted, though it is designed to never steal cycles from the processor, so the downside is limited to unused background work.
It targets the switch, not all real-time overhead. RTOSUnit accelerates scheduling and context switching, the dominant switch costs; other RTOS overheads and application-level timing behavior are outside its scope, so it improves one important component of end-to-end real-time performance.

The evaluation

Ways to handle RTOS context switching

Property	Software (standard FreeRTOS)	Memory-mapped / banked-register hardware	RTOSUnit
Register save/restore
Scheduler		Sometimes offloaded
Processor interface	Not applicable
General context switching	Yes, but slow
Latency and jitter	High latency, high jitter	Partial improvement	Up to 76 percent lower latency, jitter eliminable

Ways to handle context switching in a real-time operating system, as compared in the paper. Standard FreeRTOS does everything in software: it saves the running task's registers one at a time, runs a variable-length scheduler, and restores the next task's registers, which keeps both latency and jitter high — and since complex event handling must be deferred to a task behind a full switch, this directly limits response time and complicates worst-case timing analysis. Prior hardware approaches either offload scheduling through memory-mapped I/O (adding communication overhead) or use shadow/banked register sets that eliminate save/restore only for short interrupt handlers and cap the number of tasks, unsuitable for general switching. RTOSUnit is a configurable hardware unit integrated into the RISC-V core and driven by custom instructions for tight coupling. It offloads task scheduling to hardware, duplicates the register file to snapshot a task's whole register state in a single cycle and drain it to memory in the background, and optionally preloads the next task's context speculatively at low memory priority to hide the restore. Users configure which of store, load, and scheduling to accelerate, trading area for speed, and the design is ported to three RISC-V cores of varying complexity (a microcontroller-class, an application-class, and a superscalar out-of-order core). Across configurations it achieves up to a 76 percent reduction in mean context-switch latency and can be configured to completely eliminate jitter on selected cores, with 22-nanometer ASIC area overheads from negligible to 44 percent while maintaining viable frequencies and power; the design is open-source.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

RTOSUnit is a solid, practical computer-architecture contribution that hardens a specific, important bottleneck in real-time embedded systems. The problem is concrete: a real-time operating system like FreeRTOS makes multi-tasked embedded software far easier to write, but every context switch — saving one task’s registers, choosing the next task, restoring its registers — costs time, and that time both limits how fast the system can respond (since complex event handling waits behind a full switch) and, through its variability (jitter), erodes the predictability that worst-case timing analysis and safety certification depend on. Doing it in software makes both hard to fix. The paper’s response is to accelerate the two dominant operations, scheduling and register save/restore, in a configurable hardware unit coupled to the processor through custom instructions rather than a slow memory-mapped interface, to duplicate the register file so the whole state is snapshotted in a single cycle and written back in the background, and to optionally preload the next task’s context speculatively at low priority so the restore is hidden. The results are strong and honestly bounded: up to 76 percent lower mean switch latency, jitter eliminable entirely on suitable cores, demonstrated portably across three quite different RISC-V cores, with area overheads that the configurability lets designers dial from negligible to 44 percent, and the design open-sourced. Read the scope carefully. The biggest gains require the heaviest configuration and its area cost; the unit must be integrated into the core, not attached externally; it targets FreeRTOS on RISC-V specifically, though the ideas generalize; preloading is speculative and can be wasted if the schedule differs; and it accelerates the context switch, one component of overall real-time behavior, not every source of timing overhead. The durable idea is that when a software abstraction sits on the critical path of a system’s most important guarantee — here, real-time responsiveness and predictability — the highest-leverage move can be to co-design the hardware so the abstraction’s hot path becomes native, constant-time operations, converting a variable software cost into a fast, deterministic hardware one.

Background

Why real-time and embedded systems keep pulling functions into hardware

It helps to see RTOSUnit within a long tradition in embedded and real-time computing of pushing performance- and predictability-critical functions down into hardware, precisely because these systems are judged not on average speed but on guaranteed, bounded behavior under the worst case. Where general-purpose computing tolerates variability for throughput, real-time systems need determinism, and software running on a shared processor is an awkward place to get it, so designers repeatedly move the crucial mechanisms — interrupt handling, scheduling, context management — closer to the metal. The open RISC-V hardware work covered elsewhere on this site reflects the enabling trend that makes this practical today, an open, extensible instruction set and open cores that let researchers add custom instructions and specialized units like RTOSUnit and evaluate them across real microarchitectures without proprietary barriers. The common thread is that the flexibility of an open, modifiable processor turns co-design from a vendor privilege into a broadly available technique, so the operating-system and application functions that most constrain a real-time system’s timing can be re-implemented as hardware primitives tuned for low, predictable latency. As embedded systems take on more demanding control and safety roles, and as open hardware lowers the barrier to customizing the processor, the pattern RTOSUnit exemplifies — co-exploring the RTOS and the microarchitecture together to make the timing-critical path fast and deterministic — is likely to spread further into future embedded systems-on-chip.

If you remember only three things

1. Embedded real-time systems must respond to events within strict, guaranteed time bounds, and a real-time operating system (RTOS) like FreeRTOS makes them easier to build by offering a multi-tasking model. But every context switch — when the system stops one task and runs another — the RTOS must save the running task's register state, run the scheduler to pick the next task, and restore that task's register state, and the total time is the context-switch latency. This latency limits response time, because complex event handling that cannot finish inside an interrupt routine must be deferred to a task behind a full switch. And because switch duration varies with scheduling and task state, the spread between the longest and shortest switch (jitter) undermines the predictability that worst-case timing analysis and safety certification require. Doing scheduling and register save/restore in software — saving registers one at a time, running a variable-length scheduler on the same processor as the tasks — keeps both latency and jitter stubbornly high.
2. RTOSUnit is a configurable hardware acceleration unit that offloads FreeRTOS's scheduling and context switching, co-designed with the RISC-V processor. It is reached through new custom instructions rather than a memory-mapped interface, so the processor invokes it with minimal communication overhead. It offloads task scheduling — maintaining the ready lists and selecting the highest-priority ready task in hardware, removing the variable-length software scheduler. It duplicates the register file with a second bank so a task's entire register state is snapshotted in a single cycle and then drained to memory in the background, replacing the long, register-by-register save. And it optionally preloads the next task's context speculatively into a buffer in the background, at lower memory-arbitration priority than the processor so it never steals cycles, so that when the switch happens the restore is already largely done. Users configure which of store, load, and scheduling to accelerate, trading hardware area for speed, and the constant-time operations make the switch not just faster but deterministic.
3. Integrated into three RISC-V cores of varying complexity (a microcontroller-class, an application-class, and a superscalar out-of-order core) to demonstrate portability, RTOSUnit achieves up to a 76 percent reduction in mean context-switch latency and can be configured to completely eliminate jitter on selected cores, with 22-nanometer ASIC area overheads ranging from negligible to 44 percent while maintaining viable operating frequencies and power for embedded use; the design is open-source. Scope: the biggest gains require the heaviest, most area-costly configuration; the unit must be integrated into the core rather than attached externally; it targets FreeRTOS on RISC-V specifically though the ideas generalize; preloading is speculative and can be wasted if the schedule differs; and it accelerates the context switch, not every source of real-time overhead. The durable lesson is that when a software abstraction sits on the critical path of a system's core guarantee — real-time responsiveness and predictability — co-designing the hardware to make its hot path native, constant-time operations turns a variable software cost into a fast, deterministic hardware one.

Check yourself

Check your understanding

1. What is context-switch latency in an RTOS, and why does it matter for real-time response?
2. Why is jitter (variability in context-switch duration) a problem, and why is software switching prone to it?
3. How does RTOSUnit accelerate context switching?
4. What did RTOSUnit achieve, and what are its costs and limits?

Sources

The paper is “Co-Exploration of RISC-V Processor Microarchitectures and FreeRTOS Extensions for Lower Context-Switch Latency” by Markus Scheck, Tammo Muermann, and Andreas Koch, published at ASPLOS 2026, DOI 10.1145/3779212.3790141. The authors are at the Technical University of Darmstadt, and the design (RTOSUnit) is open-source at github.com/esa-tu-darmstadt/RTOSUnit_Integration.

This explainer is based on the full text of the paper, obtained from the authors’ open-access copy (the Creative Commons version) hosted on the Technical University of Darmstadt Embedded Systems and Applications group’s publications page. The problem framing (embedded real-time systems needing bounded response times; real-time operating systems such as FreeRTOS providing multi-tasking at the cost of scheduling and context-switch overhead; the context switch consisting of saving the running task’s register state, running the scheduler to select the next task, and restoring that task’s state; context-switch latency setting a floor on response time because complex event handling is deferred to tasks behind a full switch; and jitter, the spread between maximum and minimum switch latency, undermining worst-case execution time analysis), the analysis of prior approaches (memory-mapped hardware schedulers with communication overhead, and shadow or banked register sets and per-task register files that suit short interrupt handling or cap task counts but are unsuitable for general context switching), the RTOSUnit design (a configurable hardware unit reached through custom instructions rather than memory-mapped I/O; hardware task scheduling over the ready lists; a duplicated register file that snapshots the whole register state in a single cycle and drains it to memory in the background; and optional speculative context preloading into a buffer at lower memory-arbitration priority than the processor; with configurations selecting store, load, and scheduling acceleration), the integration into three RISC-V cores (CV32E40P microcontroller-class, CVA6 application-class, and NaxRiscv superscalar out-of-order), and the results (up to a 76 percent reduction in mean context-switch latency, configurable complete elimination of jitter on selected cores, and 22-nanometer ASIC area overheads from negligible to 44 percent while maintaining viable frequencies and power) are all drawn directly from the paper. Background explanations of RTOSes, context switching, register files, interrupt service routines, jitter, and worst-case execution time analysis are standard and provided to make the paper’s contribution understandable.