FPGA vs CPU vs GPU for Control
Each compute fabric has a place in Kronos: GPUs for offline training, CPUs for coordination, FPGAs for the timed control and protection paths.
The right tool per tier
Kronos does not favor one silicon; it matches fabric to requirement. GPUs deliver throughput for offline multi-physics and model training at L0. CPUs give flexible, ordered coordination at L2/L3. FPGAs give bounded, jitter-free timing at L1. Only the FPGA can promise a cycle-exact deadline, which is why it owns the fast loops on both machines.
Latency and determinism
- CPU: microsecond-to-millisecond response, but variance from caches, interrupts, and scheduling makes worst-case bounds loose.
- GPU: enormous parallel throughput, but kernel launch and batching add latency and jitter unfit for a 10 µs deadline.
- FPGA: sub-microsecond, cycle-exact response with WCET fixed by pipeline depth.
A comparison
| Fabric | Deterministic | Fast loop role |
|---|---|---|
| FPGA | yes | protection + inner loops |
| CPU | no | supervisory + config |
| GPU | no | offline training only |
Throughput vs timing
The GPU wins on floating-point throughput per watt for large batched work — exactly what L0's Monte Carlo neutronics and surrogate training need. But throughput is not timing. A control loop needs the same small computation to complete before a fixed deadline every cycle, which favors spatial fabric over time-shared cores. Kronos therefore trains on GPUs, then compiles the resulting gains and thresholds into FPGA fabric.
CPUs remain essential for what is not on the critical path: loading bitstreams, mediating the MPC handoff, logging to the L2 archive, and running the PLC supervisory logic. The architecture is a division of labor, not a contest.