In 01ccb69, changes to the MB CPLD code were made which caused the
following issue when updating the CPLD:
root@ni-x4xx-xxxxxxx:~# zbx_update_cpld --dboards 0
Traceback (most recent call last):
File "/usr/bin/zbx_update_cpld", line 22, in <module>
from usrp_mpm.periph_manager.x4xx_mb_cpld import MboardCPLD
ImportError: cannot import name 'MboardCPLD' from
'usrp_mpm.periph_manager.x4xx_mb_cpld'
(/usr/lib/python3.7/site-packages/usrp_mpm/periph_manager/x4xx_mb_cpld.py)
This fixes this bug.
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
These APIs are not used, and are implemented by accessing private
members of child attributes, which is not a good style. Since they are
not used or needed, they can be removed without substitute.
ZBX has a daughterboard flash memory, but other daughterboards for X4xx
do not. We therefore add a flag to class ZBX that declares its usage of
a DB flash memory, and X4xxDboardIface uses that flag to conditionally
initialize the DB flash.
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.
The classes E31x_db and Neon were importing the AD936xDboard mixin class
after their parent class, not before. This means the mixin couldn't be
used to override classes from the parent class, because Python's MRO
will go to the first class in the inheritance list.
Because there is no use of super() in these classes, the reordering has
no other effect than prioritize AD936xDboard over DboardManagerBase when
it comes to resolving parent methods.
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.
This adds a new class, X4xxDbMixin, which can be used for daughterboards
that are installed into an X4xx motherboard. It collects all the common
tasks between such daughterboards.
The mixin is also mixed into the ZBX daughterboard class. The other
dboards (IF test CCA, Debug DB) are not modified.
This API call does nothing useful, is never called, and references
non-existant attributes of the x4xx class (qspi_cs, qspi_nodes). Most
likely this was used during early revisions of X410 development and
controlled hardware that no longer exists.
This commit reverts the changes made in commit 81a9cc1f8 to reduce the
time for the LMK PLL to report lock status. The decision to revert the
change comes after an investigation found that reducing the overall time
to detect lock correlates with an increase in an error reported by the
TDC ('[ERROR] TDC measurements show a wide range of values! Check your
clock rates for incompatibilities. ... Uncaught exception in method
set_clock_source: TDC measurement out of expected range!'). Despite the
LMK PLL reporting lock status, our investigation revealed that it takes
additional time for the PLL to align the daughterboards' clocks closely
enough to pass the TDC measurement's range limit (i.e., no samples
exceeding the measurement mean +/- 500 ps). Reverting the change
increases the amount of time between achieving lock status and taking
the TDC measurements, thus greatly reducing the likelihood of the
reported error.
Add the Filter API to n3xx specifically for the AD937x device. The TX
filter is limited to 32 taps, and the RX filter is limited to 48 taps.
This feature requires MPM version 4.2 or later on the device.
Co-authored-by: bpadalino <bpadalino@gmail.com>
Signed-off-by: mattprost <matt.prost@ni.com>
Allow users to control the Mykonos frontend bandwidth settings for
Rx and Tx. Note that this operation requires the daughterboard to
re-initialize, so it may take some time. Values for frontend filter
settings were derived using ADI's AD9371 Filter Wizard.
This feature requires MPM version 4.1 or later on the device.
Co-authored-by: bpadalino <bpadalino@gmail.com>
Signed-off-by: mattprost <matt.prost@ni.com>
The ref_locked mboard sensor on the n320 always returned true without
querying hardware. On this device family, mboard sensor callback in
n3xx.py returns the "and" of its daughterboard LMK PLLs by querying the
get_ref_lock() function on each dboard manager. However, that function
only existed for the Magnesium daughterbaord. For the Rhodium
daughterboard, the function didn't exist and so a true value was
automatically returned.
This commit adds the get_ref_lock() implementations for Rhodium and
EISCAT daughterboards, which are identical to the implementation
already present for Magnesium.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
The FSRU (aka EISCAT) was never supported in UHD 4.0. The FPGA
repository never had the relevant files, and the block controller also
never existed. This removes all the corresponding files from MPM, as
well as some references from makefiles.
The LO-locked sensors on these devices were getting routed to the MPM
API call get_lo_lock_sensor(), which takes a 'which' argument (rx or
tx). However, UHD wants to pass a 'chan' argument (0 or 1). The way the
code was structured, it would always return 'False' (LO not locked) when
the argument was neither 'rx' or 'tx'.
The solution is to add get_rx_lo_lock_sensor() and
get_tx_lo_lock_sensor(), which generate the appropriate 'which'
argument, but discard the 'chan' argument (there is only one LO per Tx
and Rx, respectively).
In UHD 3, we had two sensors names for LO lock on these devices:
lo_lock, and lo_locked. The latter is the more standard, and is checked
in examples like rx_samples_to_file.
In UHD 4, the latter was removed without comment. This adds the sensor
back again and also updates the documentation accordingly.
In mpm arguments are handled as key=value pairs. Therefore setting
rfic_digital_loopback to 0 should disable the digital data loopback
inside the RFIC on N310. This fixes this behavior by correctly casting
from string to boolean but keeps the full re-init sequence when using
the rfic_digital_loopback flag.
- Reduce PLL1 DLD lock count to 4,000 (0xFA0), or 100ms
- Change loop to check for lock every 10ms
Signed-off-by: michael-west <michael.west@ettus.com>
The revision compat check for ZBX hardware is broken. It requires the
rev_compat register to read 1. However, that is the value for RevA,
which we are deliberately *not* supporting.
Supported revisions are B and C, which have a rev_compat value of 2. We
therefore change the check to support revision 2, but not 1. In the
future, we would support revisions 2 and up if there are more revs to
ZBX. Valid rev_compat values are tracked in a whitelist (which we need
to update as we produce more revisions).
This patch fixes an issue where MPM wouldn't start when ZBX revisions
B or C are plugged in.
Add DboardIface class which will act as an interface to bridge the gap
between MB and DB drivers in MPM. The DboardIface will be implemented
by each Motherboard with MB specific information. Dboard objects
will then instantiate the class in order to utilize the implemented
control functions.
This commit adds daughterboard simulation to the simulator. There is a
sim_dboard class which registers it's methods with the rpc server. These
methods are visible over mpm as well as the mpm_shell.
Signed-off-by: Samuel O'Brien <sam.obrien@ni.com>
The pca953x driver introduced a change for how the "label" property
populates. Instead of using the device model, it gives a device specific
name. As a replacement, use device/name. This affects the tca6424
and tca6408.
For the kernel change that causes this see:
5128f8d445
The ad9371 call set_master_clock_rate() can take a while depending on
the rate change, so make it asynchronous in order not to lock out the
reclaimer loop.
- Remove superfluous INFO logging
- Improve formatting in many places
- Improve Pylint score in various places
- Add tear_down to DB object
- Simplify custom EEPROM code for E310
- Fix time source selection code
- Remove references to GPS_CTRL and GPS_STATUS (are E320 only)
- Move clock source control out of MboardRegs object
Many small cleanups:
- Fix copyright headers
- Fix superfluous imports
- Pull some constants out of classes where appropriate
- Fix formatting
- Improve/fix some docstrings
- Disable specific Pylint warnings where appropriate
- Global catches use BaseException instead of Exception
- Don't use len() for empty checks
- Make sure to declare all self attributes in __init__ (note: this is
particularly of interest for E310, becuase its regular init happens
outside of __init__)
- Compacted some E310 code that had multi-DB checks
This does not change the MPM/UHD API, but it makes the set_freq() call
asynchronous on the MPM side. The upside is that it will release the GIL
if the set_freq() call takes too long, e.g., because of MPM
calibrations.
- Turns the E310 into an MPM device (like N3xx, E320)
- Factor out common code between E320 and E310, maximize sharing between
the two devices
- Remove all pre-MPM E310 code that is no longer needed
- Modify MPM to remove all existing overlays before applying new ones
(this is necessary to enable idle image mode for E310)
Co-authored-by: Virendra Kakade <virendra.kakade@ni.com>
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
Without this patch, the N320 code will rely on an error to occur to
determine the non-existence of the N321 LO distribution board. While
this works, it forces an error message where there's no error. This will
first check for the existence of the board before trying to initialize
it.
Fixes Rhodium for changes introduced in b7bab6a. The constructor call
for BfrfsEEPROM didn't match the signature, and Rhodium's EEPROM map
referred to the wrong revision.
