Improvements to firmware timing

[npetersen2]

We want to be able to run ultra-high-speed motors where our control algorithms match our simulated/modeled system assumptions. Right now, the v1 firmware timing is not very "tight," so the mathematical model/simulation does not exactly match the hardware implementation.

Issues with v1 firmware

Sensor sampling / synchronization

• We want ALL feedback signals to be sampled exactly at the same time, and this should be aligned with the PWM carrier
  • In v1 firmware, the "internal ADC" and AMDS ADCs are synchronized to the PWM carrier
  • AMDS "auto tx mode" introduces some sampling delay (but still aligned to PWM carrier)
  • "Internal ADC" is "aligned" to the PWM carrier, but it is free-running and the latest sample when the PWM carrier signal occurs is used as the feedback. This causes problems since it is not "perfectly" aligned, and at higher control/PWM rates, we cannot assume the free-running sampling rate is high enough for this assumption to work... I think it runs in the low MSPS range.
  • The encoder is not
  • The Kaman eddy current sensor is not

Control task alignment to PWM carrier

• In v1 firmware, the scheduler is time-based and fixed at the system tick frequency (e.g., 10kHz). The control task, with "high priority registering" will run exactly every 10kHz. However, this is not aligned to the PWM carrier... there is a constant time shift between these. This is bad since the model assumes these are aligned.

PWM duty cycle output timing

• If we are switching faster than the control rate, the PWM duty cycle command will get applied to the hardware "right away" after setting the FPGA registers... still aligned to the PWM carrier, but not delayed by 1 control timestep like in the modeling. This introduces fractional time step delays which the model doesn't handle. In v1 firmware, we approximately solve this by storing our desired duty cycle output to a temp C code variable, then writing it out at the beginning of the next control event. This is not exact...... the FPGA hardware should handle this for us. i.e., we write to a "shadow"/"buffer" register and tell the FPGA exactly when we want this to propagate to the output. This could be exactly 1 Ts, or we could ask it for exactly 0.5 Ts, etc.

Proposed changes

I propose to fix these issues, we create a new system module (located in sys/) that has a counterpart in the FPGA. This module will be in charge of system timing. The user configures each aspect of the above sections, and it orchestrates the sensor sampling, ISR generation, and PWM output flushing.

[npetersen2]

A draft architecture of the new FPGA structure:

[codecubepi]

It seems like this is implemented by the new timing manager IP. See #323 and the v1.3 release candidate. @npetersen2 I'm not sure what you want to do with this issue, it seems like a duplicate.