FreeRTOS multi-task demo, hardened

P43 takes the working P42 demo and turns it into a real chip. It also fixes the halt convention P42 had to work around.

Status: hardened. Directed sim PASSES at 5.10M clocks (clean halt via MMIO_HALT with halt_code = 1, exact UART sequence S a b c d e f g h D). LibreLane harden run also PASSES with 0 errors across DRC/LVS/antenna/routing/XOR, 0 setup/hold violations, slack 6.568 ns. Halt-port logic added +66 cells.

What’s new in the RTL

P43 is the first rung past P09’s halt convention. The directed runtimes for P09-P42 ended a test with jal x0, 0 (machine code 0x0000006f); the chip’s is_halt_loop decoder caught that encoding and stopped fetching. P42 found the bug: gcc -O2 emits the same encoding as the safety-net epilogue of for (;;) functions. FreeRTOS’s prvIdleTask has one. Our chip would halt itself the moment all real tasks went idle.

P43 replaces the convention with an MMIO halt port:

• New address MMIO_HALT = 0x10001ff8 in the platform module.
• A write captures wdata into a 32-bit halt_code register and pulses halt_strobe for one cycle.
• The CPU core has a new external_halt input that latches the request and transitions S_WB -> S_HALT at the next retire boundary.
• is_halt_loop is gone. jal x0, 0 is just a normal infinite loop again.

Three small surgical edits in src/top.sv. All the surrounding machinery - trap path, MMIO router, scheduler, FreeRTOS port - stayed the same.

Why MMIO halt is what other people do

Other RISC-V simulation conventions:

P43 picks the MMIO halt port option for two reasons:

1. The toolchain never accidentally emits a write to 0x10001ff8. jal x0, 0 does not have that property.
2. The RTL change is small: ~10 lines of platform module and a single latched input on the CPU core.

What this validates

P43 is the first hardened ladder rung that has actually run a real RTOS image:

• FreeRTOS V11.1.0, unmodified, in 30 KiB total image
• Three application tasks plus idle
• 1 kHz tick from MMIO mtime/mtimecmp at 25 MHz core clock
• Queue-based message passing
• Clean halt via deliberate software write

P42 proved scheduler functionality on the same RTL with a software-only workaround. P43 fixes the underlying RTL issue and hardens the result.

Harden result

LibreLane flow: PASS.

The halt-port logic added 66 cells / 1264 um^2 over P39. Slow-corner DRV continued to improve - the new halt-port flops shifted placement enough to relax two more slew offenders relative to P39.

What just happened?

The FreeRTOS arc closes here. We have a hardened RV32IM + Zicsr + Zifencei + Zicntr core with a working MMIO halt port and a real RTOS demo running on it - all on sky130A.

P43 is also the first rung where we changed RTL because real software found a real bug. The P42 idle-hook workaround was the symptom; the halt sentinel collision was the disease. The journal records both.

What’s next is open. The roadmap had P43 as the end of the FreeRTOS arc; beyond it the options diverge:

• broaden ISA (atomics, compressed)
• pipeline the core for real speed (the speed-push experiment named the divider OR-tree as the bottleneck)
• build out a richer FreeRTOS-on-this-chip software story (more demos, real peripherals, a SPI-flash boot path)

All real options. None inside P43.