Worst-Case Execution Time (WCET)

L1 certifies every critical path by its provable worst-case execution time, computed from fabric structure rather than measured averages.

Definition

WCET is the maximum time a computation can take over all admissible inputs and system states. For Kronos's control plane, WCET is not an empirical maximum from a test campaign; it is derived from the structure of the logic itself, then confirmed by measurement. Only when the analytic bound and the measured bound agree is a path admitted to a protection function.

Why fabric makes WCET tractable

On a CPU, WCET analysis must account for caches, pipelines, speculation, and OS interference, producing loose and fragile bounds. On FPGA fabric, a fully pipelined datapath has a WCET equal to its depth times the clock period — input-independent by construction. A depth-30 pipeline at 5 ns/cycle has a WCET of 150 ns, exactly, with no data dependence.

Handling data-dependent logic

Where an algorithm has variable iteration — an iterative equilibrium solve, for example — L1 either bounds the iteration count with a hard cap and a defined fallback, or moves the algorithm off the critical path entirely. A capped Newton step for the breeder's fast equilibrium delta runs a fixed number of iterations and returns the best available correction; the uncapped high-fidelity solve lives at L3.

• Loops bounded by static maximum trip counts.
• No recursion on critical paths.
• Memory access patterns fixed and pre-analyzed.
• Fallback output defined for the capped case, itself within WCET.

Certification artifact

Each protection bitstream ships with a WCET report: per-stage bounds, the composed end-to-end bound, and the margin against the deadline. This artifact is versioned with the bitstream and reviewed when either changes. It is the evidence that the sub-10 µs boundary is met, not assumed.