We currently maintain two instances for clock control: hardware and software. We use the former because it both consistently and reliably hits a (maximum) clock control update frequency of 1 MHz. While the latter does what we want in practice (clock convergence), we don't have a good idea on how long it takes to do a single clock control update. I.e.:

We don't really mind fewer updates (say, 100 KHz) but the updates should be timed reliably to make sure we can make our theory match our practice. We currently do have some timing logic implemented in Rust (firmware-support/bittide-sys/src/time.rs) backed by a hardware component bittide/src/Bittide/Wishbone.hs => timeWb but this is too slow to reliably schedule microseconds.

We should investigate what is needed to set a reliable update rate. There is no one valid solution that comes to mind, but in the end we should have a solution that:

• Can reliably hit an update mark precise to say 100 KHz.
• Gives feedback in such a way that it is immediately noticeable if the mechanism fails / the computation between updates takes too long

Relevant code:

• bittide/src/Bittide/Wishbone.hs => timeWb
• firmware-support/bittide-sys/src/time.rs: HAL for timing component
• firmware-support/bittide-sys/src/clock_control.rs: HAL for FINC/FDEC buttons
• firmware-support/bittide-sys/src/callisto.rs: Implementation of clock control algorithm ("Callisto")