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.
The update_ref_clock_freq() procedure now updates the self._init_args
value of the Rhodium class daugtherboard objects in MPM to propagate
the latest user-selected arguments for future reference.
- This is a combination of 5 commits.
- rh: add lo distribution board gpio expander
- rh: add lo distribution mpm functions
- rh: add code to conditionally initialize lo distribution
- rh: change empty i2c device from exception to assertion
- rh: add lo distribution board control
- Confirmed the Phase DAC to be initialized at mid-scale.
- Confirmed the Phase DAC step resolution for fine clock shifting.
The clock synchronization algorithm relies on the Phase DAC to fine
shift the sampling clocks on each daughterboard.
Only a certain number of DAC codes are required for the actual clock
adjustment, thus a different range of codes may be chosen by
initializing the Phase DAC with a given value. With the selected range,
one may measure the Phase DAC's linearity and step resolution, which
defines how many steps are required when performing the fine shifting
of the clocks.
After initializing the 16-bit Phase DAC at 25%, 50% (mid-scale), and
75%; it was found that the clock distribution PLL locks relatively
faster when using mid-scale (2^15). By testing the Phase DAC's
linearity, it was confirmed that the circuit resolution is 1.11 ps per
code.
- Optimized JESD204B RX/TX links' latency.
- Made JESD latency constant across supported frequencies.
- Checking RX SYSREF capture in the FPGA deframer block.
The JESD204B standard can be linked in such a way to produce a
repeatable, deterministic delay from the framer to deframer. This is
accomplished by setting up a LMFC (local multiframe clock) in both
devices.
The LMFCs are reset whenever a SYSREF edge is captured by the framer
and deframer. Therefore, it is simple to control the LMFC rising edges
in each device by implementing variable delay elements on the SYSREF
pulses to the framer and deframer.
Latency across the JESD204B TX/RX links should remain constant and
deterministic across the supported sampling_clock_rate values. By
testing the roundtrip latency (i.e. FPGA -> TX -> RX -> FPGA) with
different delay values in the FPGA, one may decrease the latency and
provide enough setup and hold margin for the data to be transfered
through each JESD link.
It was found that a different set of SYSREF delay values are required
for sampling_clock_rate = 400 MSPS to match the latency of the other
supported rates.
Summary:
This change will allow correct args to pass from mboard to dboards,
that in turn can be useful for dboard manager.
Details:
In N310, the dboard manager needs the time source to be updated before
calling update_ref_clock_source(), because it will trigger a reinit of
the dboard, for which the time_source is essential to determine correct
clock synchronizer settings.
The special case is the white rabbit time source needs a different
internal ref_clock_frequency for the clock synchronizer than the passed
in ref_clock_freq.
Added set_sync_source method to set both the time and clock sources
without forcing a re-init twice. Modified the existing set_time_source
and set_clock_source methods to call into set_sync_source.
- Fix the syntax to open mboard-regs UIO objects, and change the open()
and close() functions to be private.
- We were calling open() twice in every context manager line- once
manually, and once in __enter__. This commit corrects those usages, and
allows the context manager to fully manage the opening and closing of
UIO objects.
