Users might build X400 bitfiles without RF blocks in it. In that
case the DSP info will report 0 for both the TX and RX.
MPM needs to handle that case correct an skip RF block initialization
an fall back to default values. This will allow bitfiles without
RF to load.
When powering up the GPSDO, ensure the GPS_3V3 rail is up before taking
the GPSDO out of reset. When powering down the GPSDO, ensure I/O signals
are driven low to ensure GPSDO isn't backfed power via its I/O input pins.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
The ECHO send error occurs if the sender tries a MTU size which
is greater than what is supported in the direction from the MPM
device back to the sender. This is uncritical as the sender will
try with a smaller MTU size afterwards. Hence, demote the log
level of this message to debug and add information about the
packet size to better understand what is happening.
Importing from usrp_mpm.rpc_server imports a lot of dependencies which are
unnecessary if the rpc_server functionality is not actually needed.
Move the decorator functions to a new file rpc_utils.py and import only
from this file inside periph_manager.
usrp_hwd.py needs additional dependencies which are specifically imported:
- usrp_mpm.rpc_server.spawn_rpc_process
- usrp_mpm.discovery.spawn_discovery_process
- Bumps FPGA compat from 8.2 to 8.3
- Adds three global motherboard registers to read the 96-bit device DNA
- MPM is updated to read these registers and update the device_info if
compat version 8.3 is available
This adds an error message in MPM for detecting invalid FPGA
configurations. Specifically, it is possible to generate multiple
transport adapters with identical NODE_INST values, which causes
problems in particular when attempting raw UDP streaming.
With this error message, such FPGA bitfiles are not accepted by MPM and
will cause a exception during bitfile loading.
It is, in principle, possible to use an external clock to synchronize
N3x0 devices in frequency, and then use a GPSDO for a coarse time
synchronization. This use case is deliberately not supported, as the
GPSDO PPS signal and the external clock signal are by definition not
matched, which will remove any guarantees on time/phase alignment.
Because there are certain, niche use cases where the lack of phase
alignment is acceptable, but only an external clock is available (no
shared external PPS), usage of GPS for generating a PPS signal may be
fine. This patch does not enable the usage of this combination out of
the box, but adds comments and an update to the manual to explain the
risks of this combination, and how to enable it (by patching MPM).
If the converter rate argument was used with two values then a tuple was
created and later on compared with a list of the same contents which led
to a warning being printed. This change casts the tuple to a list to
avoid this.
When using two different master clock rates we skip the multi-tile
synchronization (MTS). Without this change however we compared the
converter rates and not the master clock rates which in some cases led
to MTS running because two different master clock rates still used the
same converter rate. This commit fixes this.
In some cases it is necessary to use the master clock rate that belongs
to the greater of the two calculated converter rates to find a sysref
configuration that matches both rates. This change takes care of that.
In X440 we've seen that the RF performance may be bad if in dual rate
the higher converter rate comes second. This change adds a warning if a
session is started in that way which proposes to swap MCRs.
While for single rate we created a fixed mapping between master clock
rate and LMK VCO rate, this prevents some of the otherwise possible
dual-rates. This change adds possible VCO rates to the MCR-VCO mapping
and enables the x400 clock policy to work with these lists.
This fixes the behavior that a non-valid dual-rate config could fall
back to a single-rate configuration with two different converter rates.
With this it also fixes the behavior that with those same master clock
rates we wouldn't run mult-tile sync (as this depends on the converter
rate).
Since in dual rate we cannot use multi-tile sync over all tiles we
disable it completely for all tiles. For 1600 MHz bitfiles this isn't an
issue at all because the two remaining channels have different converter
rates anyway. For 400 MHz bitfiles the channels with the same rate will
not be synced, either, but will most probably have a fixed phase
difference.
Co-authored-by: Martin Braun <martin.braun@ettus.com>
- Update X410 and X440 BSP YAML files to properly index clocks
- Update image core files to declare clock indices
- Update get_clocks() in MPM to return the correct values
This does not include changes to the x400_radio_control block registry.
This change by itself will thus not change behaviour.
This change adds a lookup table for the default master clock rate based
on the DSP bandwidth of the FPGA image for X440. Since the default
master clock rate currently is 368.64 MHz and we don't want to change
this for backwards compatibility, we need to have a way to handle lower
bandwidth FPGA images. This is what the LUT provides.
Change the syrnchronization order to be following:
- Run the MTS (multi-tile sync) procedure
- Run the timekeeper alignment to next_pps edge
- Run the post timekeeper alignment steps (none for now)
This ensures that any effects caused due to delay adjustments which are
part of the MTS procedure do not affect timekeeper alignment.
Without this change timekeepers on two X4xx devices would be mis-aligned
slightly in a multi-device scenario.
Note that setting all timekeepers to a common time_spec on the next_pps
as a part of post-initialization application code will still align them perfectly.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
Change all references to "gps_lock" to "gps_locked" for consistency
across the code base. Fixes incorrect use of "gps_lock" for the sensor
name on X4xx.
Signed-off-by: michael-west <michael.west@ettus.com>
To follow Xilinx' recommendations for self-cal usage this adds
startup_tile() to the cal_mode selection and we query if the cal_mode
was set properly. Since we do this, on the host side we allow the full
first Nyquist zone to be used for self-cal.
- Move the configuration of SPLL and MMCM into its own method
- In set_master_clock_rate(), call this with intermediate clock settings
if we decide that going direct from one clock setting to another would
cause harm/failures
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Before this commit, set_sync_source() would require the master clock
rate to be set after reclocking, but would pull it out of the
X4xxClockManager object (using the _master_clock_rates attribute). Now,
the new master clock rate is passed to set_sync_source() via the args
argument.
Note that it is still possible (for backward compat) to not provide
a new MCR, in which case the assumption is that the current MCR still
remains valid.
This avoids unnecessary statefulness of this function and fixes an issue
where during init(), external reference clock frequencies would be
validated against the wrong master clock rates.
This enables querying the converter rate through the sensor API:
```python
>>> U = uhd.usrp.MultiUSRP("type=x4xx")
>>> print(U.get_tx_sensor('rfdc_rate').to_real())
3000000000.0
```
This change ensures that ADC selfcal is triggered during session start
if the clocking was reconfigured. So it saves time if several
consecutive sessions are opened with always the same settings.
It also makes the ADC self cal run if in an open session either
set_clock_source(), set_time_source() or set_sync_source() are called
and a clock reconfiguration was triggered by that.
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 inherits RuntimeError and saves from logging and throwing in
separate steps. Instead of
```python
log.error("Error X occured!")
raise RuntimeError("Error X occured!")
```
do
```python
raise LogRuntimeError(log, "Error X occured!")
```
