| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This commit adds code to the convert tests to support the ability to
benchmark individual conversion test cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements some minor cleanup of various converter- and
convert test-related code:
* Improves the log messages regarding which converter was returned for a
request.
* Modifies the result checking code in the converter tests to only
report an out-of-range sample error once, rather than reporting every
out-of-range sample encountered during the test. This vastly cuts down
on the output when a conversion has failed.
* Adds a function `reverse_converter()` which, given a
`convert::id_type` describing a conversion from C1 to C2, returns a
`convert::id_type` describing the reverse conversion (C2 to C1).
* Removes two redundant test cases from the converter test.
|
|
|
|
| |
Signed-off-by: Ron Economos <w6rz@comcast.net>
|
|
|
|
|
| |
* A uhd_test.so lacks the necessary symbols for testing
due to default visibility set to hidden.
|
|
|
|
|
|
|
| |
- Add notes on playback and record behaviour
- Improve docs for play()
Co-authored-by: Wade Fife <wade.fife@ettus.com>
|
|
|
|
|
|
|
|
| |
When connecting an Rx streamer to a replay block, this now allows
requesting data from the replay block using a stream command. This will
automatically request data from all ports the streamer is connected to,
and even if there are blocks in between (depending on their action
forwarding policies).
|
|
|
|
| |
These RFNoC C++ API calls were previously not exported into Python.
|
|
|
|
|
|
|
| |
rfnoc::connect_through_blocks(), unlike rfnoc_graph::connect(), did not
have an argument to declare a back-edge. This patch remedies this
situation by adding a skip_property_propagation argument that works
exactly as with rfnoc_graph::connect().
|
|
|
|
|
| |
This was left over from when the manual was ported to Doxygen in
a74919c2. It is not used by Doxygen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a Doxygen setting where to find MathJax. The default might not
be suitable for everyone, and in particular, if people already have MJ
installed on their local system, they might prefer using that instead of
an online one.
Example usage: Assume you have MathJax installed locally, e.g., through
the mathjax package on Fedora, or the libjs-mathjax package on
Debian/Ubuntu. Then you could build UHD as such:
cmake -DMATHJAX_RELPATH=/usr/share/javascript/mathjax
This will now use the local version. Note that locally generated HTML
documentation can now no longer be copied to other machines, unless they
also have MathJax installed to the same path.
|
|
|
|
|
| |
This fixes an issue where tinfo and ncurses are split into separate
libraries.
|
| |
|
|
|
|
| |
Iterate over copy and delete from original dictionary.
|
|
|
|
|
| |
The sw_iface entry in the `control` section is yet underdefined, so we
can remove it from the block descriptors.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
UHD no longer depends on ORC since 41812aa2f (merged 2015).
|
|
|
|
|
|
|
| |
n32x is specced to 3 Mhz. Added a note about performance below
specced frequency minimums
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
| |
|
|
|
|
|
| |
The full path names can cause non-reproducible builds, because they
include the build directory.
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds DRAM support to E31x devices. Due to the size of the DDR3
memory controller, it is not enabled by default. You can include the
memory controller IP in the build by adding the DRAM environment
variable to your build. For example:
DRAM=1 make E310_SG3
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This removes the libatomic check on macOS. Like MSVC,
just assume that it's built in.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throughout UHD, we often do floating-point comparisons for frequency
ranges that require resilience to floating point rounding errors. Most
of the time the checks look like this:
```cpp
if (fp_compare_epsilon<double>(freq) > boundary) {
// ...
}
```
The exception is the N320 daughterboard control, which uses a custom
epsilon:
```cpp
if (fp_compare_epsilon<double>(freq,
RHODIUM_FREQ_COMPARE_EPSILON) > boundary) {
// ...
}
```
This was, for the most part, not by design, but because authors simply
didn't think about which epsilon value was appropriate for the frequency
comparison. This was complicated by the fact that fp_compare_epsilon
previously had some issues.
This patch introduces FREQ_COMPARE_EPSILON, which is a sensible default
value for fp_compare_epsilon when doing frequency comparisons (note that
fp_compare_delta already had such a value).
Also, it introduces freq_compare_epsilon(x), which is a shorthand for
fp_compare_epsilon<double>(x, FREQ_COMPARE_EPSILON).
We then replace all occurrences of fp_compare_epsilon<double> which are
specific to frequency checks with freq_compare_epsilon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UHD had an issue where the design of fp_compare_epsilon and its usage
differed. In fact, the *only* usage of fp_compare_epsilon outside of
unit tests was to do a fuzzy frequency comparison, and it always took
a form like this:
```cpp
// The argument EPSILON may be implied, i.e., using the default
if (fp_compare_epsilon<double>(test_freq, EPSILON) < boundary_freq) {
// ...
}
```
However, the API of fp_compare_epsilon was such that it would apply
DOUBLE_PRECISION_EPSILON to part of the frequency comparison, thus
rendering the argument EPSILON obsolete. When the default EPSILON was
used, this was OK, but only when the floating point type of
fp_compare_epsilon<> was `double`, and not `float`.
As an example, consider the following:
```
if (fp_compare_epsilon<double>(1e9 + x, LITTLE_EPSILON) == 1e9) {
// ....
}
double BIG_EPSILON = x * 10;
if (fp_compare_epsilon<double>(1e9 + x, BIG_EPSILON) == 1e9) {
// ....
}
```
If you expect the second comparison to pass even if the first failed,
then you are not alone. However, that's not what UHD would do. Because
of the aforementioned behaviour, it would use DOUBLE_PRECISION_EPSILON
for the right hand comparison, which would fail again.
Instead of fixing the instances of fp_compare_epsilon throughout UHD,
this patch changes the comparison algorithm from "very close with
tolerance epsilon" to "close enough with tolerance epsilon". This
requires only one side to be close to the other, using its own epsilon,
so the aforementioned example would always pass on the second check.
However, this exposed a second bug in fp_compare_epsilon. For
greater-/less-than comparisons, it would use epsilon like a delta value,
i.e., it would check if
a + epsilon < b - epsilon
That means that if a < b, but (b-a) < 2*epsilon, this check would return
"false", i.e., it would report that a >= b, which is incorrect. These
operators are now changed such that they first check equality of a and
b using the algorithm described in the code, and then compare the values
of a and b (ignoring epsilon) directly. A unit test for this case was
added.
|
|
|
|
|
|
| |
This changes the return value of connect_through_blocks() from void to
a list of edges. If the connection can be made, then it will now return
the list of connections between the source block and port.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following warnings:
```
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2335:5: warning: \
delete called on non-final 'uhd::rfnoc::x400::x400_gpio_port_mapping' that has \
virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
delete __ptr;
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2648:7: note: in \
instantiation of member function 'std::__1::default_delete<uhd::rfnoc::x400::x4\
00_gpio_port_mapping>::operator()' requested here
__ptr_.second()(__tmp);
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2602:19: note: in\
instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\
pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\
ping> >::reset' requested here
~unique_ptr() { reset(); }
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/memory:4063:21: note: in\
instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\
pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\
ping> >::~unique_ptr' requested here
unique_ptr<_Yp> __hold(__p);
^
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_radio_control.cpp:1\
92:33: note: in instantiation of function template specialization 'std::__1::sh\
ared_ptr<uhd::mapper::gpio_port_mapper>::shared_ptr<uhd::rfnoc::x400::x400_gpio\
_port_mapping>' requested here
auto gpio_port_mapper = std::shared_ptr<uhd::mapper::gpio_port_mapper>(
```
and:
```
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\
4:75: warning: adding 'const uint32_t' (aka 'const unsigned int') to a string d\
oes not append to the string [-Wstring-plus-int]
"Could not find corresponding GPIO pin number for given SPI pin " + value);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\
4:75: note: use array indexing to silence this warning
"Could not find corresponding GPIO pin number for given SPI pin " + value);
^
& [ ]
```
|
|
|
|
|
| |
This allows viewing or, conceivably, customizing the tuning table that
ZBX uses, depending on the particular needs of the end user.
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds a faux Sphinx project under host/docs. When invoking sphinx,
it will in fact forward the generator request to Doxygen. This is useful
for generating the UHD manual, e.g., on readthedocs.
To enable the latter service, .readthedocs.yaml and environment.yml
files were added as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the default MTU forwarding policy is ONE_TO_ONE, therefore,
it is only strictly necessary to modify the MTU forwarding policy for
blocks that route data in a different manner. However, it may be nice to
explicitly state the forwarding policy for the benefit of the reader.
The following blocks had their policies updated:
- addsub: ONE_TO_FAN
- duc: ONE_TO_ONE
- dmafifo: ONE_TO_ONE
- null block: DROP
- replay block: DROP
- split stream: ONE_TO_FAN
- switchboard: ONE_TO_FAN
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the default was DROP. For almost all RFNoC blocks, this is
not a good default. It is very easy to crash USRPs by not properly
propagating the MTU. For example, the following flow graph:
Radio -> DDC -> FIR -> Streamer
would crash an X310 when not manually setting an spp value. The reason
is: The Radio block has an output buffer of 8192 bytes, capable of
handling 2044 samples per packet. However, that's too big for the
Ethernet portion of the X310, which would cause the X310 to lose
connection between UHD and firmware. If the FIR were configured to
propagate MTU, the Host->USRP connection (which has an MTU of <= 8000)
would limit the MTU on all links, and the spp value would automatically
be reduced to 1996 (or less).
This commit uses the post_init() feature to check the user set an MTU in
the constructor, and sets it to the default if that didn't happen. This
doesn't solve all problems (the new default of ONE_TO_ONE) could also be
incorrect, but is a much more suitable default.
As a consequence, this has a minor change in how
set_mtu_forwarding_policy() can be used: It now must be called during
the constructor. Before, the rule was that it may only be called once,
but that could also have happened, e.g., during the first property
resolution. Now, the constructor is the last time block authors can
choose an MTU forwarding policy.
|
|
|
|
|
|
|
|
| |
This method allows running a fixed set of rules to check the internal
consistency of a block. This may be necessary, because blocks authors
may incorrectly implement a certain design rule, and we want the ability
to not start an RFNoC graph with blocks that have rule violations which
we can write checks for.
|
|
|
|
|
|
|
|
|
| |
The boost/lockfree/queue.hpp requires linking with the
libatomic on some platforms (e.g. s390x).
Fixes #410
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 716ed77, refactoring was performed to merge `set_tx_subdev_spec()`
and `set_rx_subdev_spec()` via the use of a shared helper function,
`_set_subdev_spec()`, which factors out differences in the two
directions by accepting lambda functions from the caller. However, there
were two bugs introduced in the refactoring:
- The channel map parameter, which is either `_rx_chans` or `_tx_chans`
based on direction, was passed by value and not reference, so changes
made by the function were not persisted in the member variables
maintained in the `multi_usrp_rfnoc` class.
- The connection removal loop checks for the presence of an SEP block on
an edge as its termination condition. In the pre-refactored code, the
direction determined whether the source or destination of the edge was
checked for the SEP. However, in the refactoring, the source of the edge
is checked for both TX and RX. While this works for the
`set_tx_subdev_spec()` call, it breaks the `set_rx_subdev_spec()` call.
This commit fixes the issue by adding another lambda parameter to the
`set_subdev_spec()` function, which puts the onus of the edge check on
the direction-specific code to ensure it is looking at the correct side
of the edge.
|
|
|
|
|
|
|
|
|
|
| |
uhd::dict gets typedefed into board_eeprom_t, which is used by applications
like uhd_usrp_probe, so this should be considered as part of the API.
fs_path is also an API, but because of MSVC build issues it
was not marked as so. Instead mark with UHD_API_HEADER.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
UHD_API sets the visibility for the symbols. Adding UHD_API fixes
casting issues seen on macOS. However this breaks Windows because
UHD_API sets __declspec(dllexport) and __declspec(dllimport) which
doesn't make sense for header/inline only definitions. This change
adds UHD_API_HEADER to denote entrypoints for this case. It sets
the visibility flags for Linux/Mac but does not set the
__declspec on Windows.
Signed-off-by: Steven Koo <steven.koo@ni.com>
|
|
|
|
|
|
|
|
|
|
| |
Constatntly incrementing endpoints was causing the entries in the
routing table on the device to be exhausted, eventually resulting in a
timeout error on control packets. Since a connection between the host
and a stream endpoint on a device in a given direction is unique, the
host endpoints can be cached and re-used. This change does that.
Signed-off-by: michael-west <michael.west@ettus.com>
|
|
|
|
|
|
|
|
| |
Previously, applying `-DUHD_BOOST_REQUIRED` to the cmake command line
would do nothing. Now, it is possible to skip Boost checking, e.g., to
only build the manual by calling
cmake -DUHD_BOOST_REQUIRED=OFF -DENABLE_LIBUHD=OFF
|
|
|
|
|
| |
Move x4xx_radio_mock_reg_iface_t and x400_radio_fixture from radio
block test into own file to reuse it more easily in the future.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the minor FPGA compat number on the device is ahead of what MPM
expects, we no longer print a warning. That's because by definition, the
FPGA is still compatible with the software in this case.
If UHD requires a certain minor compat number to enable a feature,
the appropriate behaviour would be to print a warning only for that
case.
This is the equivalent change to the MPM-only change in 88d28481.
|
| |
|
|
|
|
|
|
| |
The FPGA GPIO registers don't exactly match the pin numbering on the
front panel and in the docs. This commit changes the algorithm so that
the API presented to the user matches the front panel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 0caed5529, a change was made to ctrlpoint_endpoint's behavior such
that if a client does not care about checking for ACKs on poke or poll
operations, the code calls `wait_for_ack()` with a flag indicating that
it should not wait for the ACK, but find and remove the corresponding
response from the response queue. This prevents the queue from
potentially growing endlessly with response packets that the client
doesn't even care about.
However, this introduced a subtle, undesired behavioral change. When
`wait_for_ack()` finds the corresponding response for a request, it also
checks the status field of the response to report any errors flagged by
the hardware such as invalid command, routing error, etc. Prior to the
change mentioned above, since `wait_for_ack()` was never called when the
client doesn't want ACKs, the client would never be never notified of
any errors associated with the request. However, with the aforementioned
change in placd, when `wait_for_ack()` is called to find and remove the
unwanted response packet corresponding to the request, errors **are**
checked and reported up the user.
The behavior change was unearthed by the X410 ZBX CPLD initialization
code, which writes an initial value of 0 to all ZBX CPLD registers--even
read-only registers. A control request to write a read-only register
results in a response with CMDERR in its status field, as it should.
However, since the ZBX CPLD register initialization is performed with a
`poke32()` operation which by default doesn't wait for ACKs, this was
never a problem until the change to drain the response queue
inadvertently caused the error to surface. The result is that creating a
USRP session or RFNoC graph session to an X410 device is seen to
occasionally fail with a 'RuntimeError: RuntimeError: Failure to create
rfnoc_graph' message printed to the console.
This commit preserves the desired queue-draining behavior, but ignores
any error status on the response when it is found and removed from the
queue, thus restoring the behavior pre-0caed5529.
|