This changes the default master clock rate for X440 to 368.64 MHz which
results in a converter rate of 2.94912 GSps which is in line with what
X410 uses.
Changes:
- X410 Honors the force_reinit flag now (like N310). When given, it will
force a reinit of all clocking settings.
- When master_clock_rate is not given, and nothing else changes, then
clocking configuration will be skipped. This shaves approx. 3s of
startup time and avoids issues that can occur during clocking
configuration.
- If anything changes, incl. clock/time source, then full clock
configuration is still done.
- Multi-tile sync is done in all cases, as that happens outside of init()
This demotes the sync_tiles() error to a warning to be consistent with
what the code does. We only raise a RuntimeError if the tile latencies
are not equal for all tiles, which is a little bit later. This is where
an error log was added now.
sync_tiles() may fail with some rare user configurations but it won't
make the device unusable for all use-cases. Therefore a warning is okay
in that place while bad latencies lead to an error.
This changes the clock-configuration order of operations such that all
SPLL-related settings are applied first (including syncing R-dividers to
PPS), and only then are MMCM and RFDC configured.
Previously, syncing R-dividers would happen after everything was
configured.
This adds an updateable_components overridable dictionary into the
daughterboards base class.
On X410, because some of the FPGA compatibility stems from DB-specific
components, they are moved into class ZBX.
This change fixes issues with the reset strategy for devices that don't
use default clocking parameters. That used to cause issues when
restarting the tiles and made those devices have some bigger variations
in power measurements. For X410 this should not change the behavior
compared to uhd master.
This adds X4xxRfdcCtrl.reset_tiles(), which resets all enabled tiles and
sets their registers and settings back to initial defaults. The same
functionality was previously implemented in reset_rfdc(), but we want to
be able to reset the RFDC clocks without clearing all registers.
During device initialization, however, we retain this reset of all tiles
by modifying the initialization sequence.
Before this change, we indiscriminately first set the sync source in
init(), then the master clock rate again (it is already set in
set_sync_source(), albeit to a potentially older value).
This adds checks to the args to see if things have actually changed, and
sets all settings in one go.
FPGA:
- Split up MB registers that control daughterboard specific settings so
that daughterboards 0 and 1 could have different setings, in
preparation for future devices that require different settings.
This requires a compat number bump to 8.0.
- Add registers for additional RFDC information, including the
block/tile mapping of the individual channels, and information about
resampling capabilities
- Identify sections of code that would be specific to X410/ZBX and move
them to their own headers, so it's trivial to add device-specific
sections of code instead for other devices in the future.
- This includes constraints for clocks and I/O pins.
- Remove ability to do timed ctrlport transactions to the MB CPLD, this
was unused and possibly broken.
- Move daughterboard-specific code into its own code location
(dboards/zbx)
- Move X410-specific register documentation to its own location
(doc/X410)
- Refactor Makefiles to split out X410/ZBX specific components and allow
switching between device types
- Add 512-bit AXI interconnects
- Make number of timekeepers configurable (X410 keeps the single
timekeeper)
MPM:
- Required compat is bumped to 8.0
- Now supports new registers for detecting DSP capabilities and
multi-rate settings for the daughterboards
- Adds MMCM controls (currently unused)
Co-authored-by: Wade Fife <wade.fife@ni.com>
Co-authored-by: Ryan Marlow <ryan@lmarlow.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Resetting MMCM and RFDC separately will become a requirement once we
start to also program the MMCM. As of now, it is merely a refactoring,
and we continue to use default MMCM settings.
- Adds startup_tiles() and shutdown_tiles()
- The latter is called on tear_down() to be compliant with Xilinx'
documentation on bitstream reconfiguration
This change adds a flag to the clock policy that tells the sample PLL to
enable or disable the PLL ref clock (PRC) that goes to the
daughterboards. While for X410 the PRC is required, future USRPs may not
want the clock signal to propagate to the board.
This by itself does not enable dual-rate (or multi-mcr), but it
refactors the code to enable it in the future. Additional changes may be
required.
X4xxClockMgr is renamed to X4xxClockManager.
Before this change, x4xx_rfdc_ctrl.py had various backdoors to read out
required settings. Now that we have the clock policy object, we can
simply read them out from there.
This obviates some code paths (get_rfdc_resampling_factor(),
get_default_mcr(), set_rfdc_reset_cb()).
On tear_down() (this is most commonly seen by users when updating the
FPGA image), we add a check to verify that subcomponents of the X4xx are
actually initialized, to avoid displaying a non-fatal error message that
looks like this:
[ERROR] [MPM.RPCServer] Error in update_component while resetting:
'NoneType' object has no attribute 'tear_down'
The most common/easy way to trigger this error is by loading MPM with
a bitfile that has an invalid compat number (which would stop MPM from
initializing the RFDC controls) and then running `uhd_image_loader`
(which would force a tear_down()). In that circumstance, MPM would try
to call tear_down() on an uninitialized object.
This fixes two issues:
- RfdcRegsControl.enable_iq_swap() now is consistent with other APIs in
that it takes a channel number, not a block ID
- X4xxDboardIface.enable_iq_swap() doesn't use a backdoor API call to
fish the enable_iq_swap() API out of the _rfdc_regs object that it
doesn't own
- Add class-level attributes to store constants on the chips
- LMK04832X4xx.config() is changed use a SpllConfig object, which is
temporarily defined in x4xx_clk_mgr.py before calling config()
This change updates the call to the MB CPLD CTRL and adds logic to
distinguish between X410 and other USRPs, so that we can only force a
wrong CPLD image on a given device.
This adds a new synchronization step in the MPMD device initialization.
- Add API calls to PeriphManagerBase and rpc.py (synchronize() and
aggregate_sync_data())
- Add sane default implementations to PeriphManagerBase
Note: This adds new APIs to MPM, but we won't change the compat number
in this commit, since the new API is not yet being used.
The X4x0 device is an outlier with respect to all other MPM devices when
it comes to this API. All other MPM-devices define this API on the
daughterboard, not the motherboard.
For all the reasons laid out in dboard_manager/base.py, we move this API
call for X4x0 also into the daughterboard RPC space.
Both get_master_clock_rate() and set_master_clock_rate() are explicitly
declared @no_rpc in MPM.
This is an API breakage in the UHD/MPM communication API.
Main changes:
- x4xx_mb_cpld.MboardCPLD is renamed to X4xxMboardCPLD and is now a base
class. Specific implementations of the MB CPLD require derived classes
and have to provide their corresponding signature.
- In x4xx.py, we don't init the MB CPLD and then assert we have
a specific signature. Instead, we init the MB CPLD, and choose
a derived class based on the signature. If there is no such class,
then the same error is generated as before (by itself, this means
there is no behavioural change).
- The MB CPLD image for the X410 (ZBX daughterboards) is moved to
a derived class X410MboardCPLD.
- New: The ZBX daughterboard driver verifies that the MB CPLD image is
in fact compatible with the daughterboard. For this, the MB CPLD
control classes require a COMPATIBLE_DB_PIDS attribute.
By itself, this change has no behavioural- or API changes. However, it
allows easily slotting in new CPLD images with different signatures.
Without further modifications, it does not allow *any* CPLD image
though: The PS API (e.g., enable/disable daughterboards, CMI status,
etc.) remain the same.
For the sake of completeness, the bitfields and register offsets defined
for interacting with the MB CPLD are matched with the HDL definitions,
even for registers that aren't being used by MPM at this moment.
