fix to multi-usrp-rfnoc 'set_master_clock_rate' function

[TalFel]

Description

RFNoCs multi_usrp did not fully propagate set_master_clock_rate() to the DUC/DDC chain.

Before this change, set_master_clock_rate() updated only the radio rate. If a channel had a DUC or DDC, the adjacent converter rate was left stale:

• TX: the DUC output rate was not updated to the new radio rate
• RX: the DDC input rate was not updated to the new radio rate

That caused follow-up set_tx_rate() / set_rx_rate() calls on the same multi_usrp object to operate on outdated DUC/DDC state. In practice, after changing the master clock, setting the channel sample rate could be coerced unexpectedly because interpolation/decimation was derived from the old converter-side rate.

This change updates multi_usrp_rfnoc so that set_master_clock_rate():

• propagates the new radio rate to the attached DUC/DDC
• reapplies the previously requested per-channel TX/RX rate so the DUC/DDC continues to follow the user-requested sample rate

Which devices/areas does this affect?

multi_usrp_rfnoc object functionality.

Testing Done

Initialized multi_usrp with master_clock_rate=12.345e6
set_master_clock_rate(10e6)
set_tx_rate(1e6) // <- before this change, this was unexpectedly coerced even though the new master clock(10e6) should be interpolated by 10.

After the change, there is no coercion.

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project. See CODING.md.
• I have updated the documentation accordingly.
• I have added tests to cover my changes, and all previous tests pass.
• I have checked all compat numbers if they need updating (FPGA compat,
  MPM compat, noc_shell, specific RFNoC block, ...)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[TalFel]

I have read the CLA Document and I hereby sign the CLA

[mbr0wn]

@TalFel Which device did you test this on? I'm guessing E320?

[TalFel]

@TalFel Which device did you test this on? I'm guessing E320?

I’ve added a DUC/DDC to an E310.
I don’t have access to other RFNoC devices to test this.

[mbr0wn]

@TalFel Just a quick note to say sorry we haven't handled this yet, we're in the middle of preparing a release (which this will sadly not be part of), but we'll come back to this soon.

[mbr0wn]

I was thinking if property propagation shouldn't take care of this... but of course the main issue is the cached values. This looks good.

[mbr0wn]

@TalFel there was a missing corner case when you don't have DDCs or DUCs. I updated the PR internally and when we merge into master, this will get closed. You don't need to do anything. Thanks again for this fix!