Design Space & PPA
DULI was not built as one frozen design. Each mechanism has a cheap and an aggressive implementation, and the evaluation walks the curve from a drop-in extension to a minimum-latency one. This page is the map of that curve.
Baseline
The extension is explored on a purpose-built RISC-V real-time core, so the measurements show the cost of the mechanism rather than the quirks of a commercial pipeline:
| Property | Value |
|---|---|
| ISA / pipeline | RV32IM, 3-stage in-order, static branch prediction |
| Memory | Harvard, 64-bit instruction bus, 64-bit AHB-Lite data bus, no cache |
| Protection | 8-entry PMP, NAPOT and TOR |
| Performance | 2.77 CoreMark/MHz |
| Frequency / process | 200 MHz typical, 240 MHz max, Nangate 45 nm |
| Core area | 0.0715 mm² |
| Kernel-level interrupt | 5 cycles (hardware), 634 cycles through the microkernel |
The four dials
| Dial | Cheap end | Fast end | What it costs |
|---|---|---|---|
| IID lookup | RAM table | CPU CAM | Latency vs. core area |
| Domain tables | Main SRAM | Dedicated TCM | Bus contention vs. an extra memory port |
| Context switch | Stack to SRAM | Register bank + spill fallback | Stacking latency vs. area |
| Preempted kernel PMP | Spill to memory | Shadow bank | A few cycles vs. a shadow register set |
The five variants are the successive bottlenecks: first table lookup, then context stacking, then bus contention, then the IID itself.
V1 — minimal complexity
IID as a RAM table, context stacked to main SRAM, all tables in the same memory, no new bus port. The kernel-managed PMP is shadow-banked.
37 cycles, +23% core area (0.0878 mm²), 1.89 mW static, 22.4 µW/MHz dynamic. This is the variant for a core that must keep its existing memory interface. It is already 3× faster than the best software scheme when the target is dormant, and it costs about 3% more dynamic power in normal computation.
V2 — hiding the table latency
One dedicated TCM port holds the context stack, the longest operation. PMP and budget table accesses now overlap with stacking instead of competing with it.
29 cycles, +27% (0.0905 mm²), 1.90 mW, 23.9 µW/MHz. The added port costs little area and power; this is the sweet spot for cores that already have TCM. It is the fallback mode of V5 when its register banks are exhausted.
V3 — removing the stacking bottleneck
A register bank makes context switching zero-latency; the TCM stack stays for unbounded nesting.
17 cycles, +48% (0.1057 mm²), 2.23 mW, 23.95 µW/MHz. This matches the interrupt latency of a Cortex-R4. A second bank pushes area to +70% for nesting depth only.
V4 — resolving table contention
The PMP table moves to its own TCM port, in parallel with the budget load.
14 cycles, +51% (0.1077 mm²), 2.23 mW, 23.95 µW/MHz. This matches the kernel-level interrupt latency of a Cortex-M0 — while remaining fully isolated.
V5 — zero-latency identification
The IID becomes a CAM that is consulted inside the interrupt acknowledge cycle; 16 entries cover the six-to-eight-process consolidation scenarios the design targets.
11 cycles modeled, 15 cycles measured, +66% (0.1186 mm²), 2.53 mW, 23.6 µW/MHz. It is faster than a Cortex-M3's interrupt entry and, notably, has lower dynamic power than V3/V4 because the IID unit no longer sits on the data path. Halving the CAM to 8 entries costs +57% area; doubling to 32 costs +81%.
All variants together
| Variant | Latency (cycles) | Core area (mm²) | Area vs. base | Static (mW) | Dynamic compute (µW/MHz) | Dynamic back-to-back (µW/MHz) |
|---|---|---|---|---|---|---|
| Base core | 5 (kernel-level) | 0.0715 | 100% | 1.50 | 21.75 | 12.80 |
| V1 | 37 | 0.0878 | 123% | 1.89 | 22.40 | 25.00 |
| V2 | 29 | 0.0905 | 127% | 1.90 | 23.90 | 25.90 |
| V3 | 17 | 0.1057 | 148% | 2.23 | 23.95 | 28.65 |
| V4 | 14 | 0.1077 | 151% | 2.23 | 23.95 | 29.30 |
| V5 | 11 | 0.1186 | 166% | 2.53 | 23.60 | 26.60 |
| Kernel path | 634 | — | — | — | — | — |
Latency values for V1–V5 in the table are the hardware model; V5 measures 15 cycles end-to-end on FPGA at 50 MHz.
| Variant | Area overhead | Latency (cycles) |
|---|---|---|
| Base | 0% | 5 |
| V1 | +23% | 37 |
| V2 | +27% | 29 |
| V3 | +48% | 17 |
| V4 | +51% | 14 |
| V5 | +66% | 11 |
The back-to-back column is the extension actually working: the base core's dynamic power is 12.8 µW/MHz, and continuous interrupt delivery roughly doubles it. In ordinary computation the extension is inactive, which is why V1's dynamic overhead is only about 3%.
Area in a real SoC
The core is a small part of a microcontroller. Measuring four decapped 40 nm SoCs (a smaller process than the 45 nm test chip) puts the extension in perspective:
| SoC | Die area (mm²) | Core share | V1 extra | V2 extra | V5 extra |
|---|---|---|---|---|---|
| STM32H743 (general) | 23.78 | 0.3% | 0.07% | 0.08% | 0.20% |
| LPC55S69 (security) | 8.06 | 0.9% | 0.20% | 0.24% | 0.58% |
| ESP32-C3 (Wi-Fi IoT) | 5.18 | 1.4% | 0.31% | 0.37% | 0.91% |
| TC387 (automotive) | 56.46 | 0.1% | 0.03% | 0.03% | 0.08% |
Even on an imaginary 1 mm² die, V1 adds under 2% and V5 about 5%. On real silicon the extension is a rounding error next to flash, SRAM and peripherals.
Choosing a variant
| If you need… | Pick | Why |
|---|---|---|
| No changes to the memory interface | V1 | 37 cycles, +23% area, drop-in |
| A native TCM already exists | V2 | 29 cycles for +4% more area than V1 |
| Minimum latency, area is secondary | V5 | 11 cycles modeled / 15 measured |
| Deep nesting on a budget | V2 | Unbounded nesting, deterministic spill |
| A middle point | V3 / V4 | 17 / 14 cycles at +48% / +51% |
All variants keep the same software API and the same isolation semantics. The choice is purely a PPA decision.