Implement fast/efficient execution deadlines in software

[martijnbastiaan]

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")

[leonschoorl]

I added some measurement hardware and ran a test.

With the current setup the period between clock updates fluctuates between 405 and 414 cycles @ 125MHz.
Except for some reason on node 2, where it fluctuates between 403 and 412 cycles.
So the update frequency is 125 MHz / 414 = 0.301 MHz or 301 kHz.
And the period is 414 / 125 MHz = 3.31e-6 s or 3.31 μs

[martijnbastiaan]

@rslawson A little bit of clarification: while it's a lofty goal to get the iterations take exactly the same time on each node + speed them up, the goal of this issue is to hit a specific update rate. That is to say, we view a single iteration:

The exact moment of FINC/FDEC submission is way less important (maybe even entirely?) for calculating a proper proportional gain than the update rate.

[rslawson]

I didn't realise that this would get closed when even just one of the linked PRs got closed, oops.