Real-Time Linux vs FPGA
Real-time operating systems bound scheduling latency in software, but only fabric removes it; Kronos uses RT-Linux for supervision and FPGA for the fast loops.
Two kinds of 'real-time'
A real-time operating system (RT-Linux and similar) bounds the latency of software tasks by controlling scheduling, priorities, and interrupts. It is far more deterministic than a general-purpose OS — but its bounds are in microseconds-to-milliseconds and still subject to residual jitter from caches and the kernel. FPGA fabric removes scheduling entirely: logic is spatial, so there is nothing to schedule.
Where each belongs
- FPGA: protection and fast stability loops needing the 10 µs bound and nanosecond jitter.
- RT-Linux: supervisory coordination, sequencing, the MPC-to-L1 mediation, logging — bounded but coarser.
- PLC: plant-protection sequencing at millisecond scan cadence.
RT-Linux is the right tool for tasks that need software flexibility with a decent latency bound but not a hard microsecond deadline: managing operating states, loading bitstreams, handling the trajectory handoff, and streaming telemetry to the L2 archive. It coordinates; it does not sit on a protection path.
Why not push everything to RT-Linux
One could try to run the fast loops on RT-Linux, but proving a hard 10 µs WCET through a kernel, drivers, and shared caches is fragile and loose. The FPGA gives that bound by construction. Kronos therefore keeps the certified fast loops in fabric and uses RT-Linux for the layer that genuinely benefits from a software environment.
A clean layering
The result is a stack matched to requirements: FPGA where determinism is absolute, RT-Linux where flexible bounded coordination is needed, PLC where auditable plant sequencing is needed, and GPUs offline at L0 for training. Each layer does what it is best at, and the hard guarantees live only where they can be proven — consistent with the fabric-selection logic.