Support for Real Time ADC Sample Rate Change

[JennySmith888]

This software change allows the ADC sample rate of each tile to be updated at SoC initialization
This functionality requires the ADC tile PLL to be enabled and used as the clock source. (As far as I can tell, this is already the case in most (all?) QICK designs.

There should be no change required to existing firmwares, however it would be best practice to implement firmwares with the maximum supported sample rate to ensure users don't run into timing issues because requesting a faster sample rate will require a faster adc_axis_m. The fs check code currently caps the maximum allowable sample rate at the maximum supported adc_axis_m speed * the number of samples per axi transaction requested in the bitstream. It might also be better to use a simple PLL in the adc clock wizard configured to double the sample rate as opposed to the current MMCM config which is very optimized to the default speed and may not perform as well at other rates. I can provide the tcl code for this change if desired.

Summary of Key Changes:
I had to make some updates to config_clocks, mainly removing the overlay.download() call, and re-work the clock config, download sequence to support real-time ADC sample rate change in a way that will populate the metadata nicely. The ADC tile information is now pulled dynamically from the RFDC driver as opposed to from the static .hwh file. In the future, similar changes may need to be made to the DAC configuration creation.

Example Usage
See notebook.

[JennySmith888]

Answers to Dave's Questions from Notion:

1. What freqs can be safely changed, and to what values - the software needs to be able to check this before doing the update.
This is handled by the check_samp_freq function.

2. What happens if the clock that gets changed drives the tproc? (probably this is fine, we just need to update the tproc freq in the QickConfig?)
I'm not totally clear on this. The ADC PLL clock didn't appear to drive tproc in the 4x2 firmware.

3. What happens if the clock that gets changed is used as fabric clock for other tiles, or if the tile that gets changed uses another tile’s fabric clock? (this might be OK if you change the sampling rates of both tiles?)
If a tile's PLL frequency is changed (by updating M and FBDiv), the new frequency will propagate to tiles that use this tile as a clock source or anything in the fabric being driven by this PLL. FabClkOutDiv can change the divider applied to the PLL freq before being output to the fabric (by 2, 4, 8, or 16). The default (and lowest) FabClkOutDiv value in QICK is 2 meaning the PLL clock output that goes into the fabric is half the PLL freq. It is doubled by a clock wizard so it can serve as the ADC AXI_M clock.

4. What happens if the clock that gets changed drives a clocking wizard?
The clocking wizard will apply the same div and mult values shown in the GUI to the new input clock to produce a new output clock. For example, if the clocking wizard multiplies by 4 and divides by 2, it will double ~any input frequency. The clocking wizard has an internal VCO which should be kept within a certain range-- I believe 750 MHz to 1500 MHz (see DS925 PLL Switching Characteristics) but I think this will be the case for most feasible sample rates users would request. We can think about adding another check for this. The jitter and phase noise may also vary depending on the specific frequencies. It's probably best practice to optimize / implement the design with the maximum supported sampling rate / clock to mitigate potential timing issues.

5. Understand if there’s anything else that needs to be updated/reset after a change after an update, the affected freqs in the QickConfig need to be changed: gen/RO DDS and fabric freqs, tproc freqs?, anything else? What’s the right interface for this? Easiest if sampling rates can only be set at the beginning, at QickSoc initialization. If they can be changed later, you need to make sure that pyro users get the updated QickConfig document this so users understand when to use this, how to use this, what can go wrong.
The current implementation only allows the ADC sample rates to be adjusted at SoC initialization. This ensures the proper frequencies are populated in the configuration and propagated to all aspects of the code that need them. I don't think there's need to adjust the sample rates after initialization.