We currently do not set the calibration mode during ADC self
calbration. The default mode is selected in Vivado configuration.
Nevertheless we have seen issues where not setting the mode
lead to poor results in ADC self calibration.
This commit enable the RPC to call the set_calibration_mode
which was already implemented in our RFDC lib.
Currently the E320's integrated GPSDO can be disabled using the
"enable_gps" argment at MPM initialization time (e.g. when the radio
powers on and launches the MPM daemon). However, there is no way for
a UHD application to disable the GPSDO at connection time.
This patch allows the existing "enable_gps" arg to be accepted when
initiating an MPM session from UHD, such that an application can pass
the arg "enable_gps=0" at connection time to disable the GPSDO. The
default power state of the GPSDO is restored when the session ends.
Edit: On top of the original commit by draeman-synoptic, the MPM minor
compat number was also increased to denote new non-breaking feature
support.
Co-authored-by: mattprost <matt.prost@ni.com>
Signed-off-by: mattprost <matt.prost@ni.com>
This reverts the Raw UDP host changes which is breaking
multiple interface streaming.
Commits addb81aa5d2d6adcd3a0c7a8d59fcd96af0c1ec4^..b1ca51f97aaa2226ed6ef339fb26fbea54ab7593
are reverted.
Reverts:
doc: Update manual on streaming
examples: Add remote RX streaming example
rfnoc: Enable remote UDP streaming
mpm: e320: Enable raw UDP streaming
mpm: n3xx: Enable raw UDP streaming
mpm: x4xx: Enable transport manager adapter
mpm: Enable opt-in transport adapter control
rfnoc: Transition stream managers and mgmt_portal to topo_graph_t
rfnoc: Add topology graph object
uhd/mpm: Add API to set remote routes
mpm: xports: Add XportAdapterMgr class
- Checks FPGA compat number is 6.1
- If so, it enables the transport adapter manager
- Note that E320 may still have raw UDP streaming feature disabled. In
that case, it simply doesn't report that capability.
- Checks if the compat number is at least 8.1
- If so, enables the transport adapter managers
- Note N3xx FPGA may still not have raw UDP streaming enabled, in which
case that capability is simply not reported.
This is an addition to both PeriphManagerBase (MPM) and mb_iface (UHD).
Main changes:
- Addition of mb_iface::add_remote_chdr_route() and
mb_iface::get_chdr_xport_adapters()
- In X3x0, these APIs are stubbed out.
- In mpmd, these APIs are implemented and call the new MPM APIs (see
below)
- Addition of PeriphManagerBase.add_remote_chdr_route() and
PeriphManagerBase.get_chdr_xport_adapters()
- The PeriphManagerBase implements these APIs fully when the
'remote_udp_streaming' FPGA feature is detected.
- The MPM compat number is bumped to 4.3. UHD will continue to work with
lower compat numbers. It will query the compat number and act
accordingly.
All MPM devices use identical implementations of the transport API.
Minor differences between the actual lines of code in the various
transport adapters are due to minor optimizations, such as hard-coding
'udp' as the only valid transport type for the N3xx series.
This change moves the implementation of the transport API calls
(get_chdr_link_options() and get_chdr_link_types()) into
PeriphManagerBase. The class attributes _xport_adapter_mgrs is also
declared in that class, but defining them is left up to the individual
device implementations.
This is a set of strings, each of which describe features the FPGA has.
The purpose of this is to provide a standard location to store knowledge
about available features. Typically, the code will read the compat
numbers to see if a feature is available, and then store a corresponding
string in this set.
This code was copy/pasta'd from N3x0. In theory, X410 can have more
options regarding streaming than UDP, although for now, this function
returns the exact same as before, it's just no longer hard coded.
In commit bc8713e7af the SPI functionality was made available
conditionally depending on the FPGA version number. For this,
all SPI entries were removed from the X4XX_GPIO_SRC_RADIO variable
and put into an own variable. But therefore SPI was not available
anymore as valid source for GPIO. This change reintroduces SPI and
thus enables the SPI functionality again.
Co-authored-by: Javier Valenzuela <javier.valenzuela@ni.com>
Add support for reading the number of supported SPI slaves from
the device. This has become necessary because we may have bitfiles
with different capabilities and we want to report this back correctly.
In f73e327, we modified PeriphManagerBase to explicitly list all
required methods as per the MPM/UHD API. This had an unintended side
effect: Because the clocking methods on x4xx are imported from
X4xxClockMgr, and not defined on x4xx itself, the method used to import
methods from X4xxClockMgr onto x4xx would refuse to re-define API calls
such as set_clock_source(), get_clock_source(), and so on.
The solution is to allow _add_public_methods() to overwrite existing
methods, which means we can overwrite abstract methods from
PeriphManagerBase in this fashion.
Without this patch, UHD sessions could fail in the following manner:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=x4xx")
>>> U.get_clock_source(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_clock_source(0)
RuntimeError: RuntimeError: Error during RPC call to `get_clock_source'.
Error message: get_clock_source() not available on this device!
get_sync_sources() was not implemented for E31x and E320. Because UHD
assumes this exists, calling this would cause an error like this:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP("type=e3xx")
>>> U.get_sync_sources(0)
Traceback (most recent call last):
File "<input>", line 1, in <module>
U.get_sync_sources(0)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
'get_sync_sources'
All PeriphManagerBase childs need to implement
- get_{clock,time,sync}_source()
- get_{clock,time,sync}_sources()
- set_{clock,time,sync}_source()
So we populate PeriphManagerBase with defaults for all of those.
Currently, the default clock/time source is whatever the user configured
in the last session.
This fixes the scenario were you have any MPM device and do this:
$ benchmark_rate --args $args,clock_source=external
But whoops! You forgot to attach an external 10 MHz. PLL lock fails,
nothing works. No worries, you run it again:
$ benchmark_rate --args $args
With the previous behaviour, this would retain the setting to
'external', because there's nothing to overwrite it. You would need to
append `clock_source=internal` to get a working device again. Calling
multi_usrp::set_clock_source("internal"), or a similar API call, might
not be sufficient because the PLL lock failure might crash the program
before updating the clock source is possible.
The problem with this is twofold:
- All non-MPM devices behave differently, i.e., they have a fixed
default ('internal') which is always applied if no other option is
given. This is an internal inconsistency.
- Some applications (like gr-uhd's GRC bindings) simply don't set
a clock/time source when selecting a "default", or they try and update
the clock/time source using the API calls.
Therefore, we align the behaviour of MPM devices with the other devices,
and fall back to an internal source if nothing else is provided.
The E31x and E320 devices have one virtual daughterboard, and it is
always present. This is different from N3xx, which is where the MPM code
for these devices is based upon.
During the E3xx initialization, we make sure that our single
"daughterboard" exists and is responsive. That means we can remove some
code that tests for the availability and number of daughterboards, which
we need on N3xx (which works with zero, one, or two daughterboards).
This also allows us some minor deduplication of code.
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.
set_gpio_src takes a list of twelve sources to apply to the pins. For
the DIO mapping, this is fine, because the twelve pins are zero through
eleven. However, for the HDMI mapping, the pin indices range from one
to nineteen. This commit adds a function to convert from the set_gpio_src
list indices into the pin number.
Older DIO boards don't support all the features of newer ones, but from
the log messages, it's not clear what revision the board has. We add
a log statement to clarify.
No functional changes whatsoever, only:
- Move DioControl to its own module (x4xx_dio_control.py)
- Where PyLint was complaining about whitespace issues, fix those
- Fix import list in x4xx_periphs.py after removing DioControl
- Fix import list in x4xx.py to import DioControl from the correct
location
The X4x0 MPM code doesn't always load the object for the DIO control, it
only does that when certain checks pass (EEPROM readouts need to match
expected values). Therefore, `self.dio_control` may be NoneObject during
operations, and in other areas of the code, we already check if that's
the case.
The APIs added in c36fc5f don't have these checks, which means accessing
these new APIs may result in odd exceptions when trying to dereference
a NoneType object. By adding checks for the initialization state of
`self.dio_control`, we can avoid these and either substitute better
error messages / exception messages, or return safe values.
Note that mpmd_mb_controller also accesses this object indirectly by
checking the length of the return value of get_gpio_banks(). This check
is not affected by this change, as we now are guaranteed to return an
empty list if there is no self.dio_control.
The external power can, broadly speaking, be in one of three possible
states:
- OFF (the default)
- ON (the user has enabled external power, and it's working normally)
- FAULT (the external power has encountered a fault condition)
This commit allows the client of MPM to distinguish between these
three conditions.
So, the Python garbage collector is a bit pernicious, in that it happens
behind the scenes in a way which is difficult to predict. The rfdc_ctrl
class expects that its "lifetime" will be a single live/die cycle of the
FPGA (i.e. that when a new FPGA is loaded, it will be destructed).
However, by default the Python GC will keep the X4xxRfdcCtrl class alive
for an arbitrary amount of time, meaning that it's possible that
multiple (C++) rfdc_ctrl classes can be alive at a single time.
When the GC reaps all of these classes, libmetal segfaults when we call
metal_finish several times in a row. This change works around that
issue, if not the overall GC issue, by explicitly deleting the rfdc_ctrl
object.
