Timing Budgets and Jitter

Determinism is defined by the spread of latency, not its average; L1 engineers jitter down to nanoseconds so worst-case equals typical-case.

Jitter is the enemy

A loop with 3 µs mean latency but 20 µs tail is useless for protection; the tail is what the plasma or the DEC train experiences on a bad cycle. Kronos specifies loops by their worst case and by peak-to-peak jitter, and drives jitter toward the clock period so the distribution collapses onto a single value.

Sources of jitter

• Clock domain crossings and metastability resolution.
• Arbitration for shared links or memory.
• Interrupt latency and OS scheduling (eliminated by keeping critical logic in fabric).
• Analog front-end settling and ADC conversion variability.
• Network media access on non-deterministic fabrics (avoided via time-triggered links).

Mitigation

Kronos uses a single distributed clock reference (see clock distribution), synchronous logic across each protection channel, and time-triggered communication so a frame's transmission slot is scheduled, not contended. Where a domain crossing is unavoidable, dual-flop synchronizers with computed mean-time-between-failure keep metastability negligible over the machine lifetime.

A worked budget

Consider the breeder vertical-stability inner loop targeting a 100 µs period. Acquisition of Mirnov and flux-loop signals: 1.5 µs worst case. Fabric equilibrium delta computation: 3 µs. PF-coil current-demand update over a time-triggered link: 2 µs. Power-supply gate response: 3 µs. Sum 9.5 µs, jitter under 200 ns, comfortably inside both the 10 µs protection floor and the 100 µs period.

Budgets are living documents kept beside the bitstream. Any change — a new sensor tap, a deeper filter — is re-costed against the budget before synthesis, so timing never regresses silently. Jitter measurements from commissioning are folded back to validate the analytical bounds.